From: Ingo Molnar <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: Andrew Morton <firstname.lastname@example.org>, Rusty Russell <email@example.com>, <firstname.lastname@example.org> Subject: Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 Date: Fri, 27 Sep 2002 09:53:40 +0200 (CEST) [thread overview] Message-ID: <Pine.LNX.email@example.com> (raw) In-Reply-To: <Pine.LNX.firstname.lastname@example.org> 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
next prev parent reply other threads:[~2002-09-27 7:39 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-26 11:30 Ingo Molnar 2002-09-26 15:01 ` Linus Torvalds 2002-09-26 22:09 ` Andrew Morton 2002-09-26 22:32 ` Linus Torvalds 2002-09-27 7:53 ` Ingo Molnar [this message] 2002-09-26 22:45 ` Linus Torvalds 2002-09-26 22:56 ` Linus Torvalds 2002-09-27 11:11 ` Ingo Molnar 2002-10-04 22:47 ` Jamie Lokier 2002-10-04 23:20 ` Linus Torvalds [not found] <200209261501.g8QF1pc02251@penguin.transmeta.com> 2002-09-26 15:27 ` Ingo Molnar 2002-09-26 16:48 ` Alan Cox 2002-09-27 8:05 Martin Wirth 2002-09-27 9:27 ` Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [patch] '\''sticky pages'\'' support in the VM, futex-2.5.38-C5' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).