Date: Thu, 23 Feb 2006 14:29:54 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <ak@suse.de>, Arjan van de Ven <arjan@intel.linux.com>,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [Patch 3/3] prepopulate/cache cleared pages
Message-ID: <20060223132954.GA16074@elte.hu>
References: <1140686238.2972.30.camel@laptopd505.fenrus.org> <200602231041.00566.ak@suse.de> <20060223124152.GA4008@elte.hu> <200602231406.43899.ak@suse.de> <43FDB55E.7090607@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43FDB55E.7090607@yahoo.com.au>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1058
Lines: 24


* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> I'm worried about the situation where we allocate but don't use the 
> new page: it blows quite a bit of cache. Then, when we do get around 
> to using it, it will be cold(er).

couldnt the new pte be flipped in atomically via cmpxchg? That way we 
could do the page clearing close to where we are doing it now, but 
without holding the mmap_sem.

to solve the pte races we could use a bit in the [otherwise empty] pte 
to signal "this pte can be flipped in from now on", which bit would 
automatically be cleared if mprotect() or munmap() is called over that 
range (without any extra changes to those codepaths). (in the rare case 
if the cmpxchg() fails, we go into a slowpath that drops the newly 
allocated page, re-lookups the vma and the pte, etc.)

	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/