From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751939AbWFLNIS (ORCPT ); Mon, 12 Jun 2006 09:08:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751941AbWFLNIS (ORCPT ); Mon, 12 Jun 2006 09:08:18 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:33256 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1751939AbWFLNIS (ORCPT ); Mon, 12 Jun 2006 09:08:18 -0400 Date: Mon, 12 Jun 2006 15:07:23 +0200 From: Ingo Molnar To: Andi Kleen Cc: Michal Piotrowski , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: 2.6.16-rc6-mm2 Message-ID: <20060612130723.GA17463@elte.hu> References: <20060610092412.66dd109f.akpm@osdl.org> <20060610100318.8900f849.akpm@osdl.org> <6bffcb0e0606101114u37c8b642u5c9cc8dd566cba7c@mail.gmail.com> <20060612110537.GA11358@elte.hu> <20060612114857.GA14616@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -3.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-3.1 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 0.2 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Andi Kleen wrote: > > 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. local_irq_save()/local_irq_restore() you must have meant :-) > 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 think you are right - but if someone goes the trouble of implementing per-arch support for local increments then i'm not against it. (except if the generated code is grossly inefficient) There are architectures where cli/sti hurts alot. In any case, on x86 we should switch to a cli/sti implementation indeed - it will quite likely have alot smaller footprint than __per_cpu_offset based approaches. Although on x86_64 we'd probably be pretty OK if all per-cpu variables were in the PDA and were thus at a constant %gs-relative offset. But for now we only have data_offset in the PDA so there's one more unnecessary indirection. Ingo