lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ