From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932815AbWFMD3f (ORCPT ); Mon, 12 Jun 2006 23:29:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932817AbWFMD3f (ORCPT ); Mon, 12 Jun 2006 23:29:35 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:64731 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S932815AbWFMD3e (ORCPT ); Mon, 12 Jun 2006 23:29:34 -0400 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.1-RC1 From: Keith Owens To: Andi Kleen cc: Ingo Molnar , Michal Piotrowski , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: 2.6.16-rc6-mm2 In-reply-to: Your message of "12 Jun 2006 14:14:09 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2006 13:28:46 +1000 Message-ID: <7384.1150169326@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andi Kleen (on 12 Jun 2006 14:14:09 +0200) wrote: >Ingo Molnar writes: > >> * Ingo Molnar wrote: >> >> > >> > * Christoph Lameter wrote: >> > >> > > Sorry that patch was still against mm1. Here is a fixed up version >> > > that applies cleanly against mm2: >> > >> > i have applied both patches you sent in this thread but it still >> > triggers tons of messages: >> >> > trying to fix it i realized that i'd have to touch tons of >> > architectures, which all duplicate this piece of code: >> >> below is an updated patch that includes fixups for i386 - but the real >> fix should be to properly reduce the per-arch local.h footprint to the >> bare minimum possible, and to do this fix on the asm-generic headers. > >I think an even better approach would be to use local_save_flags() / >local_restore_flags () and then use a normal increment and get >rid of smp_processor_id completely. > >I've never seen any evidence that the complex and bloated code generated by >this is any better that just enabling/disabling interrupts. > >In the x86 world P4 has costly cli/sti, but I wouldn't expect >that problem to be very widespread. I have previously suggested a lightweight solution that pins a process to a cpu for the short duration that it accesses cpu local variables. http://lkml.org/lkml/2005/12/16/2. Time to revistit that option?