[lkml]   [2009]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: A proposal for power capping through forced idle in the Linux Kernel
On Mon, 2009-12-14 at 18:51 -0500, wrote:
> On Tue, Dec 15, 2009 at 12:21:07AM +0100, Andi Kleen wrote:
> > Salman Qazi <> writes:
> > >
> > > We'd like to get as much of our stuff upstream as we can. Given that
> > > this is a somewhat sizable chunk of work, it would be impolite of me
> > > to just send out a bunch of patches without hearing the concerns of
> > > the community. What are your thoughts on our design and what do we
> > > need to change to get this to be more acceptable to the community? I
> > > also would like to know if there are any existing pieces of
> > > infrastructure that this can utilize.
> >
> > There were a lot of discussions on this a few months ago in context
> > of the ACPI 4 "power aggregator" which is a similar (perhaps
> > slightly less sophisticated) concept.
> >
> > While there was a lot of talk about teaching the scheduler about this
> > the end result was just a driver which just starts real time threads
> > and then idles in them. This is in current mainline.
> >
> > It might be a good idea to review these discussions in the archives.
> It should be noted that most of the heat from those discussions was
> over adding the ACPI 4 mechanism to accept requests from the hardware
> platform to add idle cycles in the case of thermal/power emergencies,
> before we had the scheduler improvements to be able to do so in the
> most efficient way possible. See the description of commit 8e0af5141:
> ACPI 4.0 created the logical "processor aggregator device" as a
> mechinism for platforms to ask the OS to force otherwise busy
> processors to enter (power saving) idle.
> The intent is to lower power consumption to ride-out transient
> electrical and thermal emergencies, rather than powering off the
> server....
> Vaidyanathan Srinivasan has proposed scheduler enhancements to
> allow injecting idle time into the system. This driver doesn't
> depend on those enhancements, but could cut over to them when they
> are available.
> Peter Z. does not favor upstreaming this driver until the those
> scheduler enhancements are in place. However, we favor upstreaming
> this driver now because it is useful now, and can be enhanced over
> time.
> It looks to me that scheme that Salman has proposed for adding idle
> cycles is quite sophisticated, probably more than Vaidyanathan's, and
> the main difference is that Google wants the ability to be able to
> control the system's power/thermal envelope from userspace, as opposed
> to letting the hardware request in an emergency situation. This makes
> sense, if you are trying to balance the power/thermal requirements
> across a large number of systems, as opposed to responding to a local
> power/thermal emergency signalled from the platform's firmware.
> So it would seem to me that Salman's suggestions are very similar to
> what Peter requested before this commit went in (over his objections).

Right, so the power scheduling guys from IBM were working on something
sensible in this regard, which with a feedback control interface should
provide adequate controls to manage power consumption in a rack.

So their solution is to pack tasks into smaller sched domains allowing
up to an overload parameter, this nicely works together with things like
cpusets which can partition the load-balancing system.

[ If you configure your system into 1-cpu load-balance domains then
this will of course fail, but then that's exactly what you asked for ]

Also, since it affects SCHED_OTHER tasks only, it does not affect
determinism of RT tasks.

So what this needs is a cluster controller increasing/decreasing the
overload numbers as the power consumption gets near/far from the limit.

The problem with the ACPI 4.0 spec is that it only signals a single 'do
something' or we'll kill you hard 'soon'. Which is kinda useless.

 \ /
  Last update: 2009-12-22 20:53    [W:0.053 / U:5.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site