Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758827AbYBHX62 (ORCPT ); Fri, 8 Feb 2008 18:58:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757891AbYBHX6J (ORCPT ); Fri, 8 Feb 2008 18:58:09 -0500 Received: from cantor.suse.de ([195.135.220.2]:39072 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757773AbYBHX6H (ORCPT ); Fri, 8 Feb 2008 18:58:07 -0500 Date: Sat, 9 Feb 2008 00:58:03 +0100 From: Nick Piggin To: Arjan van de Ven Cc: David Miller , torvalds@linux-foundation.org, mingo@elte.hu, jens.axboe@oracle.com, linux-kernel@vger.kernel.org, Alan.Brunelle@hp.com, dgc@sgi.com, akpm@linux-foundation.org, vegard.nossum@gmail.com, penberg@gmail.com Subject: Re: [patch] block layer: kmemcheck fixes Message-ID: <20080208235803.GF4952@wotan.suse.de> References: <20080207103136.GG15220@kernel.dk> <20080207104901.GF16735@elte.hu> <20080207.172246.31415231.davem@davemloft.net> <47AC7093.1070003@linux.intel.com> <20080208224427.GC4952@wotan.suse.de> <47ACDE09.7020805@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47ACDE09.7020805@linux.intel.com> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1376 Lines: 29 On Fri, Feb 08, 2008 at 02:56:09PM -0800, Arjan van de Ven wrote: > Nick Piggin wrote: > >>>Maybe cpus these days have so much store bandwith that doing > >>>things like the above is OK, but I doubt it :-) > >>on modern x86 cpus the memset may even be faster if the memory isn't in > >>cache; > >>the "explicit" method ends up doing Write Allocate on the cache lines > >>(so read them from memory) even though they then end up being written > >>entirely. > >>With memset the CPU is told that the entire range is set to a new value, > >>and > >>the WA can be avoided for the whole-cachelines in the range. > > > >Don't you have write combining store buffers? Or is it still speculatively > >issuing the reads even before the whole cacheline is combined? > > x86 memory order model doesn't allow that quite; and you need a "series" of > at least 64 bytes > without any other memory accesses in between even if it would.... > not happening in practice. OK, fair enough... then it will be a very nice test to see if it helps. I'm sure you could have an arch specific initialisation function if it makes a significant difference. -- 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/