Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannothandle IRQ -1"

From: Arjan van de Ven
Date: Mon Oct 09 2006 - 03:41:01 EST


> > So yes, having software say "We want to steer this particular interrupt to
> > this L3 cache domain" sounds eminently sane.
> >
> > Having software specify which L1 cache domain it wants to pollute is
> > likely just crazy micro-management.
>
> The current interrupt delivery abstraction in the kernel is a
> set of cpus an interrupt can be delivered to. Which seem sufficient
> to the cause of aiming at a cache domain. Frequently the lower
> levels of interrupt delivery map this to a single cpu because of
> hardware limitations but in certain cases we can honor a multiple cpu
> request.
>
> I believe the scheduler has knowledge about different locality domains
> for NUMA and everything else. So what is wanting on our side is some
> architecture? work to do the broad steering by default.


well normally this is the job of the userspace IRQ balancer to get
right; the thing is undergoing a redesign right now to be smarter and
deal better with dual/quad core, numa etc etc, but as a principle thing
this is best done in userspace (simply because there's higher level
information there, like "is this interrupt for a network device", so
that policy can take that into account)


--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com

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