Linux-kernel mailing list archive 1999-32,: Re: clustering page-ins

# Re: clustering page-ins

Chuck Lever (cel@monkey.org)
Tue, 10 Aug 1999 18:57:04 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: James H. Cloos Jr.: "Re: ADSL or Cable modem support in Linux, etc.."
- Previous message: kuznet@ms2.inr.ac.ru: "Re: linux-ipsec: Re: IPSEC transport mode w/2.2.x kernels and large packets"

On Fri, 6 Aug 1999, Jamie Lokier wrote:
> Intuitively I'd go for clearing the "accessed" bits on all ptes you fill
> in except the one that really faulted.
>
> Conclusion: I don't think you should put it in do_no_page. Rather,
> write a new function preload_page in memory.c, and have filemap_nopage
> call that for each page in a cluster that is a cache hit during the
> read-ahead scan.
>
> 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.

so i see two different approaches. 1 is minimal, and leaves the existing
code intact, while 2 substantially changes generic file mapping.

1. pre-allocate pte's during read-ahead, and do read-ahead just as we've
discussed.

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.

- 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/

- Next message: James H. Cloos Jr.: "Re: ADSL or Cable modem support in Linux, etc.."
- Previous message: kuznet@ms2.inr.ac.ru: "Re: linux-ipsec: Re: IPSEC transport mode w/2.2.x kernels and large packets"