From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761197AbZFOPLP (ORCPT ); Mon, 15 Jun 2009 11:11:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756911AbZFOPLA (ORCPT ); Mon, 15 Jun 2009 11:11:00 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1]:60260 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753879AbZFOPK7 (ORCPT ); Mon, 15 Jun 2009 11:10:59 -0400 Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31 From: Pekka Enberg To: Christoph Lameter Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, kamezawa.hiroyu@jp.fujitsu.com, lizf@cn.fujitsu.com, mingo@elte.hu, npiggin@suse.de, yinghai@kernel.org, benh@kernel.crashing.org In-Reply-To: References: <1245077891.23207.48.camel@penberg-laptop> Date: Mon, 15 Jun 2009 18:11:01 +0300 Message-Id: <1245078661.23207.50.camel@penberg-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.24.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, On Mon, 2009-06-15 at 11:05 -0400, Christoph Lameter wrote: > On Mon, 15 Jun 2009, Pekka Enberg wrote: > > > > Dont do it there. Only modify the slow path. > > > > > > Look at __might_sleep(). It already has an exception for system_state != > > > RUNNING. If it still triggers then add to the condition there. > > > > But does this matter? When the debugging options are turned off, there > > are no users for "real_gfp" and thus GCC optimizes everything away. For > > debugging configs, the extra cacheline load doesn't matter, does it? > > It cleaner to have the fastpath as small as possible. Having unused > variables in there is a bit confusing. OK, I can clean this up, no problem. On Mon, 2009-06-15 at 11:05 -0400, Christoph Lameter wrote: > Also the path is performance critical. That may not matter for the debug > case in some sitiations. But there are people that keep the debugging > options on. Better to limit the impact as much as possible. > > And the "extra cacheline load does not matter" reasoning can only be > applied so many times. An extra cacheline load increases the cache foot > print of the fast path after all. The point here is that the actual debugging hooks do a whole lot more than cacheline load + alu op even in the "fastpath" case (if such a thing exists for those). Pekka