Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263195AbVBDFaJ (ORCPT ); Fri, 4 Feb 2005 00:30:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264710AbVBDFaJ (ORCPT ); Fri, 4 Feb 2005 00:30:09 -0500 Received: from ozlabs.org ([203.10.76.45]:33771 "EHLO ozlabs.org") by vger.kernel.org with ESMTP id S263098AbVBDF36 (ORCPT ); Fri, 4 Feb 2005 00:29:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16899.2175.599702.827882@cargo.ozlabs.ibm.com> Date: Fri, 4 Feb 2005 16:30:39 +1100 From: Paul Mackerras To: Christoph Lameter Cc: Rik van Riel , Marcelo Tosatti , David Woodhouse , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@osdl.org Subject: Re: A scrub daemon (prezeroing) In-Reply-To: References: <1106828124.19262.45.camel@hades.cambridge.redhat.com> <20050202153256.GA19615@logos.cnet> <20050202163110.GB23132@logos.cnet> <16898.46622.108835.631425@cargo.ozlabs.ibm.com> X-Mailer: VM 7.19 under Emacs 21.3.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1838 Lines: 38 Christoph Lameter writes: > You need to think about this in a different way. Prezeroing only makes > sense if it can avoid using cache lines that the zeroing in the > hot paths would have to use since it touches all cachelines on > the page (the ppc instruction is certainly nice and avoids a cacheline > read but it still uses a cacheline!). The zeroing in itself (within the The dcbz instruction on the G5 (PPC970) establishes the new cache line in the L2 cache and doesn't disturb the L1 cache (except to invalidate the line in the L1 data cache if it is present there). The L2 cache is 512kB and 8-way set associative (LRU). So zeroing a page is unlikely to disturb the cache lines that the page fault handler is using. Then, when the page fault handler returns to the user program, any cache lines that the program wants to touch are available in 12 cycles (L2 hit latency) instead of 200 - 300 (memory access latency). > cpu caches) is extraordinarily fast and the zeroing of large portions of > memory is so too. That is why the impact of scrubd is negligible since > its extremely fast. But that also disturbs cache lines that may well otherwise be useful. > The point is to save activating cachelines not the time zeroing in itself > takes. This only works if only parts of the page are needed immediately > after the page fault. All of that has been documented in earlier posts on > the subject. As has my scepticism about pre-zeroing actually providing any benefit on ppc64. Nevertheless, the only definitive answer is to actually measure the performance both ways. Paul. - 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/