From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754926Ab0I2SGS (ORCPT ); Wed, 29 Sep 2010 14:06:18 -0400 Received: from www.tglx.de ([62.245.132.106]:45998 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754804Ab0I2SGS (ORCPT ); Wed, 29 Sep 2010 14:06:18 -0400 Date: Wed, 29 Sep 2010 20:05:40 +0200 (CEST) From: Thomas Gleixner To: Arthur Kepner cc: "Eric W. Biederman" , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC/PATCHv2] x86/irq: round-robin distribution of irqs to cpus w/in node In-Reply-To: <20100929171941.GH3096@sgi.com> Message-ID: References: <20100927203448.GC30050@sgi.com> <20100927220113.GD30050@sgi.com> <20100929171941.GH3096@sgi.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Sep 2010, Arthur Kepner wrote: > On Mon, Sep 27, 2010 at 05:17:07PM -0700, Eric W. Biederman wrote: > > Thomas Gleixner writes: > > On Tue, Sep 28, 2010 at 03:59:33AM -0700, Eric W. Biederman wrote: > > Thomas Gleixner writes: > > > > > On Mon, 27 Sep 2010, Eric W. Biederman wrote: > > >> > On Mon, 27 Sep 2010, Arthur Kepner wrote: > > >> The deep bug is that create_irq_nr allocates a vector (which it does > > >> because at the time there was no better way to mark an irq in use on > > >> x86). In the case of msi-x we really don't know the node that irq is > > >> going to be used on until we get a request irq. We simply know which > > >> node the device is on. > > > > > > Bah. So the whole per node allocation business is completely useless > > > at this point. > > > > Probably. > > Huh? No, the patch that started this thread spreads the irqs around > and avoids the problem of a single CPU's vectors all being consumed. I'm talking about the per node memory allocations for sparse. Not the irq vectors > > > > Understood. It has taken a couple of years before this bug finally > > bit anyone waiting a release or two to get it fixed properly seems > > reasonable. > > .... > > And so what are we to do in the meantime? At the moment we're > disabling MSIX, which is a pretty unattractive workaround. I understand that. The cleanup patches are hopefully ready for the next kernel, so we can deal with that problem on top of them. Thanks, tglx