From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758205AbZEaOi3 (ORCPT ); Sun, 31 May 2009 10:38:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752507AbZEaOiV (ORCPT ); Sun, 31 May 2009 10:38:21 -0400 Received: from casper.infradead.org ([85.118.1.10]:56752 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751964AbZEaOiU (ORCPT ); Sun, 31 May 2009 10:38:20 -0400 Date: Sun, 31 May 2009 07:38:26 -0700 From: Arjan van de Ven To: Peter Zijlstra Cc: "Larry H." , Alan Cox , Ingo Molnar , Rik van Riel , linux-kernel@vger.kernel.org, Linus Torvalds , linux-mm@kvack.org, Ingo Molnar , pageexec@freemail.hu Subject: Re: [patch 0/5] Support for sanitization flag in low-level page allocator Message-ID: <20090531073826.567d1dc3@infradead.org> In-Reply-To: <1243679973.6645.131.camel@laptop> References: <20090522073436.GA3612@elte.hu> <20090522113809.GB13971@oblivion.subreption.com> <20090522143914.2019dd47@lxorguk.ukuu.org.uk> <20090522180351.GC13971@oblivion.subreption.com> <20090522192158.28fe412e@lxorguk.ukuu.org.uk> <20090522234031.GH13971@oblivion.subreption.com> <20090523090910.3d6c2e85@lxorguk.ukuu.org.uk> <20090523085653.0ad217f8@infradead.org> <1243539361.6645.80.camel@laptop> <20090529073217.08eb20e1@infradead.org> <20090530054856.GG29711@oblivion.subreption.com> <1243679973.6645.131.camel@laptop> Organization: Intel X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 May 2009 12:39:33 +0200 Peter Zijlstra wrote: > > > So if you zero on free, the next allocation will reuse the zeroed > > > page. And due to LIFO that is not too far out "often", which > > > makes it likely the page is still in L2 cache. > > > > Thanks for pointing this out clearly, Arjan. > > Thing is, the time between allocation and use is typically orders of > magnitude less than between free and use. > > > Really, get a life, go fix real bugs. Don't make our kernel slower the "make it slower" is an assumption on your part. I'm not convinced. Would like to see data! You're balancing a few things in your assumption * The %age of pages that get zeroed on free, but not used in time and get flushed from L2 before they are used * The %age of pages that today doesn't get zeroed versus * The %age of the page that you are not going to read if you zero on use but does wipe a portion of L1 cache add to that * Reading a just allocated page is much more rare than writing to it. It's just zeros after all ;-) it is unclear (and cpu dependent) if writing makes it matter if the old (zero) data is in the cache or not, reducing the value of your "but it's now in the cache" value argument. * My assumption is that allocations are more latency sensitive than free. After all, on allocate, you're going to use it, while on free you're done with what you wanted to do, and performance of that on average is assumed by me to matter less. * We "need" to zero-on-allocate while holding the mmap semaphore, on free we clearly don't. We know this gives lock contention in highly threaded workloads... and zero-on-free gets rid of that entirely. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org