[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160249585.3000.159.camel@laptopd505.fenrus.org>
Date: Sat, 07 Oct 2006 21:33:05 +0200
From: Arjan van de Ven <arjan@...radead.org>
To: Linus Torvalds <torvalds@...l.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
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>
Subject: Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannot
handle IRQ -1"
> This is one of those age-old questions: in _theory_ you can do a better
> job in software, but in _practice_ it's just too damn expensive and
> complicated to do a perfect job especially with dynamic decisions, so in
> _practice_ it tends to be better to let hardware make some of the
> decisions.
it seems the right mix at this time is to have the software select the
package, and the hardware pick the core within the package.
Or rather, the software picks which cache domain (and I only count the
largest cache, not L1) and the hardware then has the freedom to do the
right thing inside that. Binding interrupts to a cache domain seems to
be still the right strategy (at least for frequent interrupts like
networking), but to do that right more higher level info is needed than
that the hw has in general. Within the package... it's the opposite
ballgame.
--
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