Hi Sebastian, you guess for ELF header seems to be valid to me. When executables or binaries are loaded memory, it is done through mmap call to the file, and to understand what file is and what binary handler in kernel can handle its section, kernel needs to know its header first, which is within the first page of the header with fixed location for a magic number (identifier for binary handler e.g. ELF handler which further loads its other sections by reading section table). Note that there are multiple binary format handles within the kernel e.g. ELF, A.OUT which are tried sequentially to identify the file format. >From the file system perspective, mmap does not use vfs_read or vfs_write calls at all, thats why you don't see them. It directly works on address space operations of an inode (file) to populate data in page-cache. For a mmapped region, if you don't see a page in memory, kenel page faults and tries to read-in the page using readpage method of address_space_operations. Similarly when you modify a page, writepage method is called, but since executables are accessed read-only, you won't see writepage method getting called either. Hope this makes it clearer. Rajat On Thu, Jan 6, 2011 at 3:45 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi... > > On Thu, Jan 6, 2011 at 03:16, Sebastian Pipping <sebastian@xxxxxxxxxxx> wrote: >> When analyzing the kernel logs I produced I noticed stumbled over the >> case of a few libraries where only the beginning of the file (maybe its >> ELF header) was read repeated times, but nothing after: >> >> file /lib/ld-2.11.2.so >> max offset+count 456 >> total bytes read ever 502840 >> >> Especially as libc is among them, I guess some reads pass by me somehow. >> Any ideas what is shoveling the file bytes around? >> >> I found calls to do_mmap_pgoff for these file, though. >> That's when I thought I may need help understanding how mmap works. > > AFAIK, mmap will eventually calls VFS read in the case of major fault. > However, in other cases the content could already be in page cache, > that's why you don't see any filesystem or block device related > operation. > > As we know, ld.so and libc.so are one of the most linked library.... > therefore it is very likely they are already in the page cache. "But I > saw initial read, why is that?". IMHO that's because filesystem layer > need to make sure, it is the same file which is already cached in the > page cache. > > To be precise, inode number, in which major and minor block device it > resides...and possibly other determinant factor. Just after it is > decided it's the same, page cache could be 100% > utilized..again..assuming all the content of ld.so and libc.so stays > in cache and never get flushed back. > > Take the above hint with lots of salt, ok? :D > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
