Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833Ab2FEVPf (ORCPT ); Tue, 5 Jun 2012 17:15:35 -0400 Received: from www.linutronix.de ([62.245.132.108]:47635 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752109Ab2FEVPd (ORCPT ); Tue, 5 Jun 2012 17:15:33 -0400 Date: Tue, 5 Jun 2012 23:15:16 +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: 1469 Lines: 39 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. 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/