[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0912101915430.10307@asgard.lang.hm>
Date: Thu, 10 Dec 2009 19:16:35 -0800 (PST)
From: david@...g.hm
To: Arjan van de Ven <arjan@...radead.org>
cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Dimitri Sivanich <sivanich@....com>,
Ingo Molnar <mingo@...e.hu>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Yinghai Lu <yinghai@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
David Miller <davem@...emloft.net>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v6] x86/apic: limit irq affinity
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
--
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