[RFC] Merge softirq, local_irq_count, local_bh_count

From: Keith Owens (kaos@ocs.com.au)
Date: Thu Jul 27 2000 - 09:44:16 EST


At the moment (2.4.0-test5-pre6) all architectures have a common
definition for softirq_state. However the definitions for
local_irq_count and local_bh_count are all over the place, some
architectures use a cache aligned structure, some use arrays of
integers (lets you play cache ping/pong), some even use locks!

Each arch defines its own way of getting to local_irq_count and
local_bh_count. To add insult to injury, not all architectures use the
mapping macros, there are bits of code scattered around that use hard
coded array lookups which are not optimized for SMP vs non-SMP.

ftp://ftp.ocs.com.au/pub/2.4.0-test5-pre6-softirq-bh-merge.gz is a
merge of softirq, local_irq_count and local_bh_count into one
structure. The aim was :-

* Put all these fields in a per-cpu cache line. They are hit by the
  same code paths and are only ever updated from one cpu. Softirq was
  already cache aligned but the other fields were not, in most cases we
  were using multiple cache lines for this data.

* Replace all the explicit references like __local_irq_count[cpu] with
  wrapper macros. Some arch's had already done this but there was
  quite a bit of crud left.

* Replace multiple arch definitions and export of irq_stat with a
  common one, optimized for SMP or non-SMP.

* Create a standard definition for the wrappers that can be used by
  almost all architectures. Only s390 and (maybe) sparc64 are special
  cases but every arch had its own slightly incompatible definition.

* Add a per-cpu syscall_count, ready for performance reporting on soft
  interrupts as well as hard interrupts. This field is not being set
  at the moment but will be easy to update once the above patch is
  accepted.

I have updated all architectures except s390 and sparc64, both of which
use locks for no apparent reason, the fields should all be cpu local
data. I'm waiting for responses from maintainers before changing those
architectures.

The patch compiles on i386, both SMP and non-SMP, I will check IA64
tomorrow. Could the other arch maintainers try the patch, it is almost
guaranteed to contain some Assembler errors.

Files patched:

arch/alpha/kernel/alpha_ksyms.c
arch/alpha/kernel/entry.S
arch/alpha/kernel/irq_alpha.c
arch/alpha/kernel/irq_smp.c
arch/alpha/kernel/smp.c
arch/arm/kernel/entry-common.S
arch/arm/kernel/irq.c
arch/i386/kernel/entry.S
arch/i386/kernel/i386_ksyms.c
arch/i386/kernel/io_apic.c
arch/i386/kernel/irq.c
arch/i386/kernel/traps.c
arch/ia64/kernel/entry.S
arch/ia64/kernel/ia64_ksyms.c
arch/ia64/kernel/irq.c
arch/m68k/kernel/entry.S
arch/m68k/kernel/ints.c
arch/m68k/kernel/m68k_ksyms.c
arch/mips/baget/irq.c
arch/mips/dec/irq.c
arch/mips/kernel/entry.S
arch/mips/kernel/irq.c
arch/mips/kernel/mips_ksyms.c
arch/mips/kernel/scall_o32.S
arch/mips/orion/irq.c
arch/mips/sgi/kernel/indy_int.c
arch/mips64/kernel/entry.S
arch/mips64/kernel/scall_64.S
arch/mips64/kernel/scall_o32.S
arch/mips64/sgi-ip22/ip22-int.c
arch/mips64/sgi-ip27/ip27-irq.c
arch/ppc/kernel/entry.S
arch/ppc/kernel/irq.c
arch/ppc/kernel/local_irq.h
arch/ppc/kernel/ppc_ksyms.c
arch/s390/kernel/entry.S
arch/s390/kernel/process.c
arch/sh/kernel/entry.S
arch/sh/kernel/irq.c
arch/sparc/kernel/irq.c
arch/sparc/kernel/rtrap.S
arch/sparc64/kernel/rtrap.S
include/asm-alpha/hardirq.h
include/asm-alpha/smp.h
include/asm-alpha/softirq.h
include/asm-arm/hardirq.h
include/asm-i386/hardirq.h
include/asm-ia64/hardirq.h
include/asm-m68k/hardirq.h
include/asm-m68k/softirq.h
include/asm-m68k/system.h
include/asm-mips/hardirq.h
include/asm-mips64/hardirq.h
include/asm-mips64/processor.h
include/asm-mips64/smp.h
include/asm-ppc/hardirq.h
include/asm-ppc/softirq.h
include/asm-sh/hardirq.h
include/asm-sh/softirq.h
include/asm-sparc/hardirq.h
include/asm-sparc/irq.h
include/asm-sparc/softirq.h
include/linux/interrupt.h
include/linux/irq_cpustat.h
kernel/ksyms.c
kernel/sched.c
kernel/softirq.c
net/netsyms.c

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:23 EST