![]() | |||||||||||
Messages in this thread |
> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-10-09 09:43 [from the cache] ©2003-2008 | |||||||||||