Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 04 Aug 2008 12:43:01 -0700 | Subject | Re: [PATCH 02/04] x86: add get_irq_cfg in io_apic_64.c |
| |
Mike Travis <travis@sgi.com> writes:
>> arch/x86/kernel/io_apic_64.c | 181 +++++++++++++++++++++++++++++++++---------- >> 1 file changed, 141 insertions(+), 40 deletions(-) >> >> Index: linux-2.6/arch/x86/kernel/io_apic_64.c >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/io_apic_64.c >> +++ linux-2.6/arch/x86/kernel/io_apic_64.c >> @@ -57,7 +57,11 @@ >> >> #define __apicdebuginit(type) static type __init >> >> +struct irq_cfg; >> + >> struct irq_cfg { >> + unsigned int irq; >> + struct irq_cfg *next; >> cpumask_t domain; >> cpumask_t old_domain; > ^^^^^^^^^ > One thought here... most interrupts cannot be serviced by any cpu in > the system, but instead need to be serviced by the cpu attached to > the ioapic or on the local node. So defining some subset of cpumask_t > would save a lot of space. For example: > > nodecpumask_t { > int node; > DEFINE_BITMAP(..., MAX_CPUS_PER_NODE); > }; > > And of course, providing some utilities to convert nodecpumask_t <==> > cpumask_t. > > ("node" might not be the proper abstraction... maybe "irqcpumask_t"?
I agree this is someplace we could optimize. In practice we seem to have 3 choices on x86.
1) A single cpu. 2) lowest priority interrupt delivery to a set of possibly 8 cpus. 3) A class of interrupt that is delivered locally to each individual cpu.
If you have a true NUMA system it should still be possible to handle interrupts on the wrong Node just prohibitively expensive.
Eric
| |