From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262953AbVAFRzB (ORCPT ); Thu, 6 Jan 2005 12:55:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262957AbVAFRvo (ORCPT ); Thu, 6 Jan 2005 12:51:44 -0500 Received: from omx2-ext.sgi.com ([192.48.171.19]:27352 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S262954AbVAFRrV (ORCPT ); Thu, 6 Jan 2005 12:47:21 -0500 Date: Thu, 6 Jan 2005 09:47:08 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Andi Kleen cc: linux-kernel@vger.kernel.org Subject: Re: Prezeroing V3 [2/4]: Extension of clear_page to take an order parameter In-Reply-To: Message-ID: References: <41C20E3E.3070209@yahoo.com.au> 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 On Thu, 6 Jan 2005, Andi Kleen wrote: > Christoph Lameter writes: > > > Here is an updated version that is independent of the first patch and > > contains all the necessary modifications to make clear_page take a second > > parameter. > > I still think the clear_page order addition is completely pointless, > because for > order 0 you probably want a cache bypassing store > in a separate function. I would think that having clear_page avoid loading cache lines from memory should be general improvement. Bypassing the cache may be beneficial for clear_page in general but I would like to test that first. If this is not a win then it may be better to implement the bypassing the cache through a zero driver. > Removing it would also make the patch much less intrusive. Right. I also thought about that. I will likely offer the clear_page patch as an optional component in V4. Being able to specify an order with clear_page also helps in other situations like clearing huge pages.