On Mon, 2009-12-14 at 18:51 -0500, tytso@xxxxxxx wrote: > On Tue, Dec 15, 2009 at 12:21:07AM +0100, Andi Kleen wrote: > > Salman Qazi <sqazi@xxxxxxxxxx> 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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
