On Sat, 23 Dec 2017, vcap...@pengaru.com wrote: > On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote: > Added the following instrumentation: > > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index 93edc2236282..7034eda4d494 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct > apic_chip_data *d, > cpumask_and(vector_searchmask, vector_searchmask, mask); > BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata, > &d->cfg.dest_apicid)); > + > + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector, > cpumask_first(vector_searchmask)); > + > return 0; > } > > This is what I see: > > Upon playing song in cmus (on AC power since boot): > Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1 > > Yank AC: > Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1 > Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector > > So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in > the added printk. > > It seems like the affinity changes are assuming a strict adherence to > the CPU mask when the underlying hardware is treating it more as a hint. > Perhaps handlers still need to be maintained on all CPUs in a given apic > domain, regardless of what the masks are configured as, to cover these > situations.
That's odd. I'll have a look after the holidays. Merry Christmas! Thanks, tglx