lkml.org 
[lkml]   [1999]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: clustering page-ins
On Wed, 11 Aug 1999, Jamie Lokier wrote:
> Chuck Lever wrote:
> > > preload_page() should duplicate some of the code in do_no_page(): it
> > > should fill in a pte, but only if the pte is "not present" already, and
> > > the new pte should be marked "old" not "young". If any memory
> > > allocation is required (for pgds and pmds) it should simply return
> > > without doing the allocation.
> >
> > actually, i think you'd want to do just the opposite. allocating the
> > extra pmds and ptes during read-ahead is exactly what you want to do,
> > while diddling the entries in already existing pte's will just break page
> > faulting in subtle ways.
>
> 1. What do you mean by "allocating extra ptes during read-ahead"? You mean
> allocate pmds when read-ahead crosses a table boundary, e.g. every 1024
> pages on x86?

allocate the necessary structs for all pages that are faulted in via
read-ahead -- of course some of that won't result in an allocation, but
simply an extra lookup operation. see below.

> > 2. fault in and map in entire clusters at a time. if the page fault
> > happens on the first page in a cluster, then watch for sequential cluster
> > faults, and do read-ahead.
>
> I still don't see what you mean be pre-allocate ptes without faulting in
> pages. Are you proposing to store "not present" references to the
> read-ahead physical pages so that future faults can avoid the hash
> lookup?

well, not store them (although it could be useful to cache them somehow),
but do the lookup and make sure the memory is allocated while waiting for
the original fault I/O to complete. in other words, when the page is
finally faulted and mapped, we're sure we do only a lookup, and not an
allocation of any kind.

> so many questions :-)

don't worry, i probably don't know what i'm talking about anyway... :)

i'll try to post a patch soon, that will probably explain a little better.
it's pretty simplistic, but i think it will convey my idea.

- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/


-
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    [W:1.071 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site