[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1206052318420.3086@ionos>
Date: Tue, 5 Jun 2012 23:33:19 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <andi@...stfloor.org>
cc: Peter Zijlstra <peterz@...radead.org>,
"Luck\\\\, Tony" <tony.luck@...el.com>,
"Yu\\\\, Fenghua" <fenghua.yu@...el.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Ingo Molnar <mingo@...e.hu>, H Peter Anvin <hpa@...or.com>,
"Siddha\\\\, Suresh B" <suresh.b.siddha@...el.com>,
"Mallick\\\\, Asit K" <asit.k.mallick@...el.com>,
Arjan Dan De Ven <arjan@...ux.intel.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, linux-pm <linux-pm@...r.kernel.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Re: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or
nmi
On Tue, 5 Jun 2012, Thomas Gleixner wrote:
> On Tue, 5 Jun 2012, Andi Kleen wrote:
> > Thomas Gleixner <tglx@...utronix.de> writes:
> > >
> > > Vs. the interrupt/timer/other crap madness:
> > >
> > > - We really don't want to have an interrupt balancer in the kernel
> > > again, but we need a mechanism to prevent the user space balancer
> > > trainwreck from ruining the power saving party.
> >
> > Why not? I think the kernel is exactly the right place for it.
> > It's essentially a scheduling problem. Scheduling in user space
> > is not a good idea.
>
> No argument about scheduling in user space. Though the real problem is
> where do you draw the line between mechanism and policy?
>
> > With MSI-X the drivers just want a static setting. User space
> > shouldn't mess with it.
> >
> > Some of the workarounds for user space messing with it (like that
> > interrupt rmap code) are really bad and just a workaround for doing the
> > scheduling in the wrong place.
> >
> > For dynamic changes it should indeed by part of scheduling,
> > following similar rules, with only high level policy input
> > from userland.
>
> I'd be happy to see a patch which implements all of that and avoids
> the pitfalls of the old in kernel irq balancer along with the short
> comings of the user space one.
And aside of the above requirements it should add the ability to deal
with the fact that aside of server workloads this needs to be able to
cope with appplications in the embedded/mobile space which know more
about the future system state than the scheduler itself.
Thanks,
tglx
--
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