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

[Arjan van de Ven <arjan@infradead.org>]

> > 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