lkml.org 
[lkml]   [1999]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans