Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 27 Sep 2002 03:39:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 27 Sep 2002 03:39:13 -0400 Received: from mx1.elte.hu ([157.181.1.137]:53988 "HELO mx1.elte.hu") by vger.kernel.org with SMTP id ; Fri, 27 Sep 2002 03:39:12 -0400 Date: Fri, 27 Sep 2002 09:53:40 +0200 (CEST) From: Ingo Molnar Reply-To: Ingo Molnar To: Linus Torvalds Cc: Andrew Morton , Rusty Russell , Subject: Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1812 Lines: 43 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/