lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 09 Oct 2006 09:40:05 +0200 From: Arjan van de Ven <arjan@...radead.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Linus Torvalds <torvalds@...l.org>, Muli Ben-Yehuda <muli@...ibm.com>, Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Rajesh Shah <rajesh.shah@...el.com>, Andi Kleen <ak@....de>, "Protasevich, Natalie" <Natalie.Protasevich@...SYS.com>, "Luck, Tony" <tony.luck@...el.com>, Andrew Morton <akpm@...l.org>, Linux-Kernel <linux-kernel@...r.kernel.org>, Badari Pulavarty <pbadari@...il.com>, Roland Dreier <rdreier@...co.com> Subject: Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannot handle IRQ -1" > > 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists