Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5

[Andrew Morton <akpm@digeo.com>]

Ingo Molnar wrote:
> 
> ...
> another implementation would be an idea from Linus: the page's lru list
> pointer can in theory be used for pinned pages (pinned pages do not have
> much LRU meaning anyway), and this pointer could specify the 'owner' MM of
> the physical page. The COW fault handler then checks the sticky page:

Overloading page->lru in this way is tricky.   If we can guarantee
that the page is anonymous (anonymise it if it's file-backed, pull
it out of swapcache) then fine, ->mapping, ->list.next, ->list.prev,
->index and ->private are available.

Can we do that?

>  - if the faulting context is a non-owner (ie. the fork()-ed child), then
>    the normal COW path is taken - new page allocated and installed.
> 
>  - if the faulting context is the owner, then the pte chain is walked, and
>    the new page is installed into every 'other' pte. This needs a
>    cross-CPU single-page TLB flush though. The TLB flush could be
>    optimized if we had a way to get to the mapping MM's of the individual
>    pte chain entries - is this possible?

Going from a pte back up to the owning MM is possible, yes.  See
mm/rmap.c:try_to_unmap_one().  The caller would have to hold the
page's rmap_lock.