Question on mmap / expecting more calls to vfs_read

[Rajat Sharma]

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 at gmail.com> wrote:
> Hi...
>
> On Thu, Jan 6, 2011 at 03:16, Sebastian Pipping <sebastian at pipping.org> 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>