Re: 230-objrmap fixes for 2.6.3-mjb2

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Mar 03, 2004 at 11:07:39AM -0600, Dave McCracken wrote:
> 
> --On Wednesday, March 03, 2004 17:57:46 +0100 Andrea Arcangeli
> <andrea@suse.de> wrote:
> 
> >> There was talk at one point of moving the "unswappable" state down into 
> >> the struct page. Is that still realistic? It would seem rather more
> >> efficient, but I forget what problem we ran into with it.
> > 
> > that already exists and it's PG_reserved, but it's inefficient compared
> > to VM_RESERVED, since it forces the vm to check all ptes.
> 
> What we've actually discussed before was more along the lines of PG_locked
> to match VM_LOCKED, but the main idea was to be able to skip over
> ineligible pages without having ot look up their mappings during pageout.

I'm not very excited using PG_locked for that, that doesn't only mean
"unswappable", it means also that the page is under I/O (or uner some
other operation that needs serialization like unmapping the page) which
is quite a different concept from VM_LOCKED. a wait_on_page would
deadlock on such a PG_locked page, while wait_on_page on a page of a
mlocked vma doesn't normally deadlock.

But I see what you want to do here, and PG_reserved would be too much
for that since it changes the semantics for cow and free_pages, but
PG_locked doesn't look good enough either, the VM_LOCKED and PG_locked
concept is quite different, PG_reserved and VM_RESERVED is quite close
instead (except for the page->count accounting).