Messages in this thread | | | Date | Sat, 27 Sep 2008 21:44:24 +0200 | From | Ingo Molnar <> | Subject | Re: Should irq_chip->mask disable percpu interrupts to all cpus, or just to this cpu? |
| |
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> writes: > > > I found handle_percpu_irq() which addresses my concerns. It doesn't > > attempt to mask the interrupt, takes no locks, and doesn't set or test > > IRQ_INPROGRESS in desc->status, so it will scale perfectly across > > multiple cpus. It makes no changes to the desc structure, so there > > isn't even any cacheline bouncing. > > kstat_irqs. Is arguably part of the irq structure. > And kstat_irqs is a major pain in my book. > > And for a rare event you have a cacheline read. > I don't think we are quite there yet but we really want to allocate > irq_desc on the right NUMA node in a multi socket system, to reduce > the cache miss times.
note that we already do _almost_ that in tip/irq/sparseirq. dyn_array[] will extend itself in a NUMA-aware fashion. (normal device irq_desc entries will be allocated via kmalloc)
what would be needed is to deallocate/reallocate irq_desc when the IRQ affinity is changed? (i.e. when a device is migrated to a specific NUMA node)
> Is it a big deal? Probably not. But I think it would be a bad idea > to increasingly use infrastructure that will make it hard to optimize > the code. > > Especially since the common case in high performance drivers is going > to be, individually routable irq sources. Having one queue per cpu > and one irq per queue. Which sounds like the same case you have.
agreed - the kstat_irqs cacheline bounce would show up in Xen benchmarks i'm sure.
Ingo
| |