Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756751AbZJFJQu (ORCPT ); Tue, 6 Oct 2009 05:16:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756711AbZJFJQu (ORCPT ); Tue, 6 Oct 2009 05:16:50 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:35204 "EHLO e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756341AbZJFJQs (ORCPT ); Tue, 6 Oct 2009 05:16:48 -0400 Date: Tue, 6 Oct 2009 14:46:06 +0530 From: Balbir Singh To: Len Brown Cc: Linus Torvalds , Andrew Morton , rjw@sisk.pl, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, a.p.zijlstra@chello.nl, shaohua.li@intel.com, svaidy@linux.vnet.ibm.com Subject: Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1 Message-ID: <20091006091606.GA6818@balbir.in.ibm.com> Reply-To: balbir@linux.vnet.ibm.com References: <20091005033256.GA26592@balbir.in.ibm.com> <200910052159.24920.rjw@sisk.pl> <20091005140415.57f1db5e.akpm@linux-foundation.org> <20091005154021.129a8f9f.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1977 Lines: 46 * Len Brown [2009-10-05 21:28:18]: > > ... we probably never want to even try > > to solve it in the scheduler, because why the hell should we care and add > > complex logic for something like that? > > Today we take cores down to 100% idle, one at a time. > This is useful, but isn't the best we can do. > > For we get zero "uncore" power savings. > As long as at least one core is active anywhere in the system, > all the uncores in all the packages in the system must remain active. > > What a scheduler-based solution could do is > instead of taking, say, 1 of 64 cores down for 100% > of the period, it could take all 64 cores down > for 64th of the same period. This could get the hardware > into the deeper "package C-states", for a measurable > net power savings. > > At the same time, this system-wide throttling may mitigate > some of the fairness/availability issues raised regarding > taking cores 100% off-line. > > But doing this optimally will not be trivial. > The hardware must stay in the deep-sleep-states long enough > to make it worth the energy to enter and exit those states. > The hardware will flush the caches, having a performance > impact on all the cores. Device interrupts would prevent > the cores from sleeping, so they'd need to be somehow delayed > if we are to sleep long enough to make sleeping worth it etc. > My concern is the side-effects of an approach like this. In the case that was pointed out earlier about hotplug breaking CPUSets, this solution can lead to starvation (single CPU in a cpuset). Most distros will enable this feature right? So most end users will see this thread running when ACPI 4.0 firmware decides to do thermal throttling. -- Balbir -- 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/