* Christoph Lameter <cl@xxxxxxxxx> 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 <cl@xxxxxxxxx> > > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
