Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753091Ab2FEVdh (ORCPT ); Tue, 5 Jun 2012 17:33:37 -0400 Received: from www.linutronix.de ([62.245.132.108]:47727 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117Ab2FEVdg (ORCPT ); Tue, 5 Jun 2012 17:33:36 -0400 Date: Tue, 5 Jun 2012 23:33:19 +0200 (CEST) From: Thomas Gleixner To: Andi Kleen cc: Peter Zijlstra , "Luck\\\\, Tony" , "Yu\\\\, Fenghua" , Rusty Russell , Ingo Molnar , H Peter Anvin , "Siddha\\\\, Suresh B" , "Mallick\\\\, Asit K" , Arjan Dan De Ven , linux-kernel , x86 , linux-pm , "Srivatsa S. Bhat" Subject: Re: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi In-Reply-To: Message-ID: References: <1338833876-29721-1-git-send-email-fenghua.yu@intel.com> <1338842001.28282.135.camel@twins> <87zk8iioam.fsf@rustcorp.com.au> <1338881971.28282.150.camel@twins> <3E5A0FA7E9CA944F9D5414FEC6C7122007727023@ORSMSX105.amr.corp.intel.com> <1338912565.2749.9.camel@twins> <3E5A0FA7E9CA944F9D5414FEC6C7122007728081@ORSMSX105.amr.corp.intel.com> <1338913190.2749.10.camel@twins> <3908561D78D1C84285E8C5FCA982C28F19300965@ORSMSX104.amr.corp.intel.com> <1338918625.2749.29.camel@twins> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1839 Lines: 45 On Tue, 5 Jun 2012, Thomas Gleixner wrote: > On Tue, 5 Jun 2012, Andi Kleen wrote: > > Thomas Gleixner 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/