Messages in this thread | | | Date | Wed, 11 Aug 1999 15:14:46 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: 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/
| |