Stephen C. Tweedie wrote:
>
> Hi,
>
> On Sat, 30 Jan 1999 12:00:53 -0500 (EST), "Benjamin C.R. LaHaise"
> <blah@kvack.org> said:
>
> > Easily isn't a good way of putting it, unless you're talking about doing
> > something like mmap on /dev/mem, in which case you could make the
> > user/kernel virtual spilt weigh heavy on the user side and do memory
> > allocation yourself.  If you're talking about doing it transparently,
> > you're best bet is to do something like davem's suggested high mem
> > approach, and only use non-kernel mapped memory for user pages... if you
> > want to be able to support the page cache in high memory, things get
> > messy.
>
> No it doesn't!  The only tricky thing is IO, but we need to have bounce
> buffers to high memory anyway for swapping.  The page cache uses "struct
> page" addresses in preference to actual page data pointers almost
> everywhere anyway, and whenever we are doing something like read(2) or
> write(2) functions, we just need a single per-CPU virtual pte in the
> vmalloc region to temporarily map the page into memory while we copy to
> user space (and remember that we do this from the context of the user
> process anyway, so we don't have to remap the user page even if it is in
> high memory).
>
There is another possibility if you want to extend the page cache:
Add a 'second level cache':
if shrink_mmap wants to discard a page from the page cache, it is saved
in the physical memory cache.
if __find_page() can't find a page in the normal cache, it checks if it
is in the physical memory cache. If so, the entry is copied into the
normal cache. You only have to modify three or four lines in filemap.c &
pagemap.h.

I've attached a patch that extends the page cache, but it's incomplete:
there is no way to configure the cache, and it's ugly.

Manfred