Messages in this thread | | | Date | Thu, 26 Sep 2002 15:09:12 -0700 | From | Andrew Morton <> | Subject | Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |