Messages in this thread | | | Date | Mon, 2 Aug 1999 22:19:38 -0400 (EDT) | From | Benjamin LaHaise <> | Subject | Re: clustering page-ins |
| |
On Mon, 2 Aug 1999, Chuck Lever wrote:
> On Fri, 30 Jul 1999, Stephen C. Tweedie wrote: > > On Thu, 29 Jul 1999 15:04:25 -0400 (EDT), Chuck Lever <cel@monkey.org> said: > > > yes, since they are sharing the same file in the same page cache it > > > would be silly to trigger read-ahead needlessly, even if it finds all the > > > pages already in the page cache. > > > > You have totally lost me. Given that each thread will share both the > > vmas _and_ the page tables, multiple threads accesing the pages is > > absolutely no different to one thread faulting pages in the same order. > > i'm not clear on when vma's are shared.
vma's are shared when mm's are shared -- between threads. That's the only time.
> say separate processes are sharing a file (say, a system log file, or > /etc/passwd) and reads are sequential. the problem isn't scheduling too > many read-ahead I/O's, it's that every process reading this "shared" file > sequentially will trigger the read-ahead code. this generates a whole > bunch of page cache lookups that could be avoided. not a big deal, but it > would be nice if the logic was smart enough to avoid it -- if read-ahead > is, say, 4 clusters, that's 64 extra page cache lookups every time that > part of the file is requested by some process.
Yeap, so how's about choosing to do readahead on mmaps by peeking at ptes in the requesting process' page tables? That gives us the ability to handle tiled access patterns for no extra cost, is easy to implement and low cost. Note that the issue of page cache lookups can be intelligently solved by increasing the size of a 'page' as stored in the page cache, and filling in page tables preemptively to avoid the faults. However, keep in mind that page cache lookups are not very expensive as the lookup is hash based, and if it ever is a problem, then preformance can be improved by throwing memory at it.
-ben
- 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/
| |