Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758392Ab0BDQnn (ORCPT ); Thu, 4 Feb 2010 11:43:43 -0500 Received: from nlpi129.sbcis.sbc.com ([207.115.36.143]:57955 "EHLO nlpi129.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758335Ab0BDQnl (ORCPT ); Thu, 4 Feb 2010 11:43:41 -0500 Date: Thu, 4 Feb 2010 10:42:53 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@router.home To: Richard Kennedy cc: penberg , Ingo Molnar , Thomas Gleixner , lkml , linux-mm Subject: Re: [RFC] slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big? In-Reply-To: <1265217903.2118.86.camel@localhost> Message-ID: References: <1265206946.2118.57.camel@localhost> <1265217903.2118.86.camel@localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1637 Lines: 41 On Wed, 3 Feb 2010, Richard Kennedy wrote: > gives me this output :- > 32 bit : size = 12 , offset of l = 4 > 64 bit : size = 16 , offset of l = 8 > > Doesn't that suggest that it would be safe to use sizeof(void *) ? > (at least on x86 anyway). Maybe. But the rule of thumb is to align objects by their size which we would be violating. A 64 bit object may span multiple cachelines if aligned to a 32 bit boundary. Which may result in nasty surprise because the object can no longer be read and written from memory in an atomic way. If there is a guarantee that no 64 bit operation ever occurs then it may be fine. Fetching a 64 bit object that straddles a cacheline boundary also requires 2 fetches instead of one to read the object which can increase the cache footprint of functions accessing the structure. Slab allocators (aside from SLOB which is rarely used) assume the minimal alignment to be sizeof(unsigned long long). > We end up with a large number of buffer_heads and as they are pretty > small an extra 4 bytes does make a significant difference. > On my 64 bit machine I often see thousands of pages of buffer_heads, so > squeezing a few more per page could be a considerable saving. On your 64 bit machine you wont be able to do the optimization that you are talking about. The buffer head structure is already fairly big so this wont make too much of a 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/