From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932322AbWJIHkm (ORCPT ); Mon, 9 Oct 2006 03:40:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932323AbWJIHkm (ORCPT ); Mon, 9 Oct 2006 03:40:42 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:61871 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S932322AbWJIHkl (ORCPT ); Mon, 9 Oct 2006 03:40:41 -0400 Subject: Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannot handle IRQ -1" From: Arjan van de Ven To: "Eric W. Biederman" Cc: Linus Torvalds , Muli Ben-Yehuda , Ingo Molnar , Thomas Gleixner , Benjamin Herrenschmidt , Rajesh Shah , Andi Kleen , "Protasevich, Natalie" , "Luck, Tony" , Andrew Morton , Linux-Kernel , Badari Pulavarty , Roland Dreier In-Reply-To: References: <20061005212216.GA10912@rhun.haifa.ibm.com> <20061006155021.GE14186@rhun.haifa.ibm.com> <20061006202324.GJ14186@rhun.haifa.ibm.com> <20061007080315.GM14186@rhun.haifa.ibm.com> <1160249585.3000.159.camel@laptopd505.fenrus.org> Content-Type: text/plain Organization: Intel International BV Date: Mon, 09 Oct 2006 09:40:05 +0200 Message-Id: <1160379606.3000.195.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.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