Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764204AbYCEA2k (ORCPT ); Tue, 4 Mar 2008 19:28:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760558AbYCEA2Y (ORCPT ); Tue, 4 Mar 2008 19:28:24 -0500 Received: from mail.suse.de ([195.135.220.2]:55908 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760125AbYCEA2X (ORCPT ); Tue, 4 Mar 2008 19:28:23 -0500 Date: Wed, 5 Mar 2008 01:28:21 +0100 From: Nick Piggin To: Pekka Enberg Cc: Christoph Lameter , netdev@vger.kernel.org, Linux Kernel Mailing List , yanmin_zhang@linux.intel.com, David Miller , Eric Dumazet Subject: Re: [rfc][patch 1/3] slub: fix small HWCACHE_ALIGN alignment Message-ID: <20080305002821.GD1510@wotan.suse.de> References: <20080303093449.GA15091@wotan.suse.de> <20080303200613.GC8974@wotan.suse.de> <20080303201701.GF8974@wotan.suse.de> <84144f020803031330i2c0ea1f6kc5b02c8b26145797@mail.gmail.com> <47CC6F30.50802@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CC6F30.50802@cs.helsinki.fi> 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: 1840 Lines: 38 On Mon, Mar 03, 2008 at 11:35:44PM +0200, Pekka Enberg wrote: > Hi, > > Christoph Lameter wrote: > >Well the guarantee can only be exploited if you would check the cacheline > >sizes and the object size from the code that creates the slab cache. > >Basically you would have to guestimate what the slab allocator is doing. > > > >So the guarantee is basically meaningless. If the object is larger than a > >cacheline then this will never work. > > Yes, I know that. That's why I am asking why this matters. If there's > some sort of regression because SLUB does HWCACHE_ALIGN bit differently, > we need to fix that. It started out as a SLUB regression that was exposing poor code in the percpu allocator due to different SLUB kmalloc alignments. That prompted some further investigation about the alignment handling in the allocators and showed up this problem with SLUB's HWCACHE_ALIGN. While I don't know of a regression caused by it as such, it is totally unreasonable to just change the semantics of it (seemingly for no good reason). It is used quite a bit in networking for one, and those guys count every single cache miss in their fastpaths. > Not that it necessarily means we have to change > HWCACHE_ALIGN but I am assuming Nick has some reason why he wants to > introduce the SMP alignment flag. The SMP flag was just an RFC. I think some people (like Christoph) were being confused about the HWCACHE_ALIGN flag being for avoiding false sharing on SMP systems. It would actually be also generally useful to have the SMP flag (eg. see the sites I added it to in patch #3). -- 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/