Re: [RFC] clustered apic irq affinity fix for i386

Martin J. Bligh (mbligh@aracnet.com)
Wed, 30 Apr 2003 21:07:07 -0700


>> This should be better. Thanks for the comments.
>
> Remind me again what the patch actually does? It seems to be purely
> adding debug checks?
>
> Won't it just go BUG if someone boots the kernel and then tries to
> manually set affinity?

Just ignoring the idiot caller would seem better, IMHO. BUG is a little
extreme ;-) Personally I'm happy for clustered apic mode machines with
irqbalance *disabled* to just fail the call. With it enabled, they can just
fraggle the affinity for irqbalance, and be happy.

> Seems a bit racy too. setup_ioapic_dest() does:
>
> pending_irq_balance_apicid[irq] = mask;
> ==> window here
> set_ioapic_affinity(irq, mask);
>
> ioapic_lock is not held, so there is a window where
> pending_irq_balance_apicid[irq] can be set to some other value and
> io_apic_write_affinity() will accidentally go BUG.
>
>
> Is it not possible to fix set_ioapic_affinity() for real for clustered
> APIC mode? What is involved in that?

The hardware doesn't support arbitrary cpumasks. However, as long as
we're running irqbalance, it doesn't matter - we only do one cpu at a time
anyway.

The existing code in the mainline kernel is wrong for platforms other than
clustered apic mode too. irqbalance is happily rotating us one cpu at a
time, and then we go along and put our big masky foot in the thing, and
splat it across multiple CPUs. If irqbalance is on, all we need to do is
set up the irqbalance mask, then force a rebalance immediately.

M.

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