From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pentafluge.infradead.org ([213.146.154.40]:58412 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751540AbXKBK2z (ORCPT ); Fri, 2 Nov 2007 06:28:55 -0400 Subject: Re: [patch 0/7] [RFC] SLUB: Improve allocpercpu to reduce per cpu access overhead From: Peter Zijlstra In-Reply-To: <20071101.155805.65012933.davem@davemloft.net> References: <20071101.153824.91808126.davem@davemloft.net> <20071101.155805.65012933.davem@davemloft.net> Content-Type: text/plain Date: Fri, 02 Nov 2007 11:28:46 +0100 Message-Id: <1193999326.27652.348.camel@twins> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org To: David Miller Cc: clameter@sgi.com, akpm@linux-foundation.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca, penberg@cs.helsinki.fi List-ID: On Thu, 2007-11-01 at 15:58 -0700, David Miller wrote: > Since you're the one who wants to change the semantics and guarentees > of this interface, perhaps it might help if you did some greps around > the tree to see how alloc_percpu() is actually used. That's what > I did when I started running into trouble with your patches. This fancy new BDI stuff also lives off percpu_counter/alloc_percpu(). That means that for example each NFS mount also consumes a number of words - not quite sure from the top of my head how many, might be in the order of 24 bytes or something. I once before started looking at this, because the current alloc_percpu() can have some false sharing - not that I have machines that are overly bothered by that. I like the idea of a strict percpu region, however do be aware of the users.