From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 6 Nov 2006 09:15:39 -0800 (PST) From: Christoph Lameter Subject: Re: Page allocator: Single Zone optimizations In-Reply-To: <200611061807.16890.ak@suse.de> Message-ID: References: <200611061756.00623.ak@suse.de> <200611061807.16890.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andi Kleen Cc: Andrew Morton , Mel Gorman , Andy Whitcroft , Nick Piggin , KAMEZAWA Hiroyuki , Linux Memory Management List , Peter Zijlstra List-ID: On Mon, 6 Nov 2006, Andi Kleen wrote: > I know this. > > > And you are right: It does not matter for those that > > have never been used. > > This means it is fine to replace the constructor with an function > that runs after kmem_cache_alloc() in this case. No its not. RCU means that there are potential accesses after a object has been freed and even after an object has been reallocated via kmem_cache_alloc. A function that runs after kmem_cache_alloc() may mess up the lock state. > What I meant: some time ago i had patches to add a __GFP_ZERO queue to the > page allocator. The page allocator would handle all this for everybody. > For various reasons they never got pushed. Yup that was probably my patchset. The problem was that I could not make the case that this was beneficial if all cache lines of a page were touched. It was a significant performance benefit only for sparsely accessed pages. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org