Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932457AbYCEAQn (ORCPT ); Tue, 4 Mar 2008 19:16:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754901AbYCEAQ1 (ORCPT ); Tue, 4 Mar 2008 19:16:27 -0500 Received: from ns2.suse.de ([195.135.220.15]:47586 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753197AbYCEAQ0 (ORCPT ); Tue, 4 Mar 2008 19:16:26 -0500 Date: Wed, 5 Mar 2008 01:16:21 +0100 From: Nick Piggin To: Christoph Lameter Cc: netdev@vger.kernel.org, Linux Kernel Mailing List , yanmin_zhang@linux.intel.com, David Miller , Eric Dumazet Subject: Re: [rfc][patch 2/3] slab: introduce SMP alignment Message-ID: <20080305001621.GC1510@wotan.suse.de> References: <20080303093449.GA15091@wotan.suse.de> <20080303093529.GB15091@wotan.suse.de> <20080303200355.GB8974@wotan.suse.de> <20080303201211.GE8974@wotan.suse.de> <20080303202411.GH8974@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2079 Lines: 57 On Mon, Mar 03, 2008 at 01:31:14PM -0800, Christoph Lameter wrote: > On Mon, 3 Mar 2008, Nick Piggin wrote: > > > On Mon, Mar 03, 2008 at 12:17:20PM -0800, Christoph Lameter wrote: > > > On Mon, 3 Mar 2008, Nick Piggin wrote: > > > > > > > > You want two ways of specifying alignments? > > > > > > > > I want a way to ask for SMP friendly allocation. > > > > > > Then align the objects at cacheline boundaries by providing a value for > > > the align parameter to kmem_cache_create(). > > > > max(num_possible_cpus() > 1 ? cache_line_size() : 0, mandatory_alignment)? > > The mandatory alignment is applied anyways. You do not need to max() on > that. No that's the caller's required alignment. > One could simply specify cache_line_size() with Pekka's patch. > cache_line_size() could default to 0 if !SMP. That's totally wrong and stupid. > > Then suppose we want a CONFIG_TINY option to eliminate it? > > No slab allocator supports that right now. That's way I said suppose we want it. Which is not unreasonable. > However, SLOB in the past has > ignored the alignment in order to reduce memory use. So maybe Matt wants > to introduce this? > > > And maybe the VSMP guys will want to blow this out to their internode > > alignment? > > > > max(!CONFIG_TINY && num_possible_cpus() > 1 ? (is_vsmp ? internode_alignemnt : cache_line_size()) : 0, mandatory_alignment) > > No the slab allocators were optimized for VSMP so that the > internode_alignment is not necessary there. That was actually one of the > requirements that triggered the slab numa work. What do you mean internode_alignment is not necessary there? This is about memory returned by the allocator to the caller, and the caller does not want any false sharing of the cacheline on SMP systems. How can internode alignemnt be not necessary? -- 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/