Messages in this thread | | | Date | Fri, 27 Sep 2002 09:53:40 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 |
| |
On Thu, 26 Sep 2002, Linus Torvalds wrote:
> Well, we have two situations: > - the page is shared. In which case we don't need to put it on any > pinning list, since the very sharedness of the page means that we won't > be COW'ing it in this address space. > - the page is private. In which case we can (and should) pre-COW it and > make it anonymous at futex time. > > So yeah, it should be doable.
well, 4 fields: ->mapping, ->list.next, ->list.prev, ->index and ->private is *alot* of space to do something smart in struct page itself.
(hm, dont we have named anonymous mappings? (ie. mmap()-ing of a file via MAP_PRIVATE?) And if a futex is put there it can be COW-ed, right, while it's also in the pagecache?)
assuming those 4 fields are available, it should be easy for the futex code to detect such mappings - the ->mapping field should be a good test, if it's NULL then it's a COW-able page, if it's non-NULL then not.
then eg. the ->private field could be used as a simple PG_sticky counter.
or, to implement real lazy COW, the ->private field could be used as an 'owner MM' pointer, and if the COW handler sees current->mm == owner_mm, then the ->list has a queue of pending page_change_struct's, which would trigger a rehashing of the futexes. Then PG_sticky is cleared.
this would work fine as long as the pin_page code guarantees to never put a hash on an already COW-ed page. (which can be guaranteed by using the 'writable' flag to get_user_pages())
no additional hashes. Is there any danger in going into this direction?
Ingo
- 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/
| |