From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [GIT PULL] slab fixes for 3.2-rc4 Date: Thu, 22 Dec 2011 19:03:29 +0100 Message-ID: <20111222180329.GA24544@elte.hu> References: <20111220162315.GC10752@google.com> <20111220202854.GH10752@google.com> <20111221170535.GB9213@google.com> <20111222160822.GE17084@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx3.mail.elte.hu ([157.181.1.138]:58500 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755559Ab1LVSFV (ORCPT ); Thu, 22 Dec 2011 13:05:21 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Christoph Lameter Cc: Tejun Heo , Linus Torvalds , Pekka Enberg , Andrew Morton , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Thomas Gleixner * Christoph Lameter wrote: > On Thu, 22 Dec 2011, Tejun Heo wrote: > > > Yeap, and that one too. Maybe we can finally kill the duplicate > > confusing static/dynamic accessors too. I'm planning to get to it in > > several weeks but if anyone can beat me to it, please go ahead. > > That would be great. I looked at _and and _or and they both still have one > use case (_xor has none though). But its easy to get rid of the irqsafe > variants once we are willing to take the additional overhead that comes > with disabling interrupts for the fallback cases. > > > Subject: [percpu] Remove irqsafe_cpu_xxx variants > > We simply say that regular this_cpu use must be safe regardless of preemption > and interrupt state. That has no material change for x86 and s390 implementations > of this_cpu operations. However, arches that do not provide their own implementation > for this_cpu operations will now get code generated that disables interrupts > instead of preemption. > > Signed-off-by: Christoph Lameter > > --- > arch/s390/include/asm/percpu.h | 50 ++++----- > arch/x86/include/asm/percpu.h | 28 ----- > include/linux/netdevice.h | 4 > include/linux/netfilter/x_tables.h | 4 > include/linux/percpu.h | 190 ++++--------------------------------- > include/net/snmp.h | 14 +- > mm/slub.c | 6 - > net/caif/caif_dev.c | 4 > net/caif/cffrml.c | 4 > 9 files changed, 65 insertions(+), 239 deletions(-) While this is progress, i think you have missed the essence of Linus's observations: percpu.h is *way* too complex and is offering way too many variants. The irqsafe madness was just the most blatant problem. Note that even wit your patch applied linux/percpu.h is 800+ lines long, while the total number of usecases is smaller than that - and then i havent even considered all the arch percpu.h files. Why not implement Linus's suggestion of just one or two __this_cpu() ops and be content with that model? Thanks, Ingo