Re: [PATCH v6] x86/apic: limit irq affinity

From: david@lang.hm
To: Arjan van de Ven <arjan@infradead.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Dimitri Sivanich <sivanich@sgi.com>, Ingo Molnar <mingo@elte.hu>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Yinghai Lu <yinghai@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	David Miller <davem@davemloft.net>,
	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v6] x86/apic: limit irq affinity
Date: Thu, 10 Dec 2009 19:16:35 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.0912101915430.10307@asgard.lang.hm> (raw)
In-Reply-To: <20091125074033.4c46c1b0@infradead.org>

On Wed, 25 Nov 2009, Arjan van de Ven wrote:

>> I think the irq scheduler is the only scheduler (except for batch
>> jobs) that we don't put in the kernel.  It seems to me that if we are
>> going to go to all of the trouble to rewrite the generic code to
>> better support irqbalance because we are having serious irqbalance
>> problems, it will be less effort to suck irqbalance into the kernel
>> along with everything else.
>
> we had that; it didn't work.
> what I'm asking for is for the kernel to expose the numa information;
> right now that is the piece that is missing.

but if there is only one userspace app, and that app has no user 
accessable configuration, what is the difference between telling everyone 
they must use that app and having the logic from that app in the kernel?

David Lang