Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* Len Brown <lenb@kernel.org> [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