Why? It is not dirty or strange. Isn't that what madvise if for... to
hint to the VM how you are going to access the mapping?
> - If read() caused prefetching of blocks, the when a page faulted in
> from an mmap() mapping, why wouldn't this cause prefetching?
>
>You have to "prime" the read prefetcher first by asking for a couple
>big chunks via read() first.
Hmmm... sound exactly like what madvise() would do.
When you say read() what exactly do you mean? Not the libc read() or
the kernel side of it, correct? I assume that you mean some place deeper
that actually is responsible for checking the cache and calling down to
do the I/O if necessary, am I somewhere in the area here?
(relying on how I assume this is working, from the previous paragraph) How
big of chunks? If a page is sufficient to prime the read prefetcher, then
wouldn't the faults cause the read prefetcher to start fetching ahead?
> - When a binary executable image is mmap()ed to be run, wouldn't you want
> to prefetch blocks of code and data -- what would be the difference
> between this and the user mmap()ing in a file?
>
>Sure, but what is your limit to pre-faulting pages in? I tried this
>once and hit this very problem. FreeBSD and some other systems have a
>hard coded limit of the number of pages to do this for as a ceiling, I
>think this is not the answer.
I don't really see the problem: some indecision on an arbitrary limit?
This is the same thing as prefetching with read(), isn't it? You don't
know how much to prefetch with read, do you? As a worst case, why not
have the same semantics as read -- prefetch the next page if you have to
sleep to read it -- not optimal, but at least will bring mmap() to the
performance of read().
I always thought that mmap() should be fast, especially when you use
it for IPC.
>The problematic case (and a real life one) is when all of libc has
>been faulted into main memory by various processes, when you start one
>up do you map in all of libc when it gets mmap'd by the application?
>If not, then which if any pages do you choose?
>
I cannot parse this.
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com
>
Lates, going to sleep now, thanks for the answer.
-jay
P.S., is there anything like the BSD book for Linux? Some postscripts
or something?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/