Messages in this thread | | | Date | Tue, 21 Aug 2012 17:13:24 +0100 | From | Matthew Garrett <> | Subject | Re: [discussion]sched: a rough proposal to enable power saving in scheduler |
| |
On Tue, Aug 21, 2012 at 05:59:08PM +0200, Ingo Molnar wrote: > * Matthew Garrett <mjg@redhat.com> wrote: > > The scheduler's behaviour is going to have a minimal impact on > > power consumption on laptops. Other things are much more > > important - backlight level, ASPM state, that kind of thing. > > So why special case the scheduler? [...] > > I'm not special casing the scheduler - but we are talking about > scheduler policies here, so *if* it makes sense to handle this > dynamically then obviously the scheduler wants to use system > state information when/if the kernel can get it. > > Your argument is as if you said that the shape of a car's side > view mirrors is not important to its top speed, because the > overall shape of the chassis and engine power are much more > important. > > But we are desiging side view mirrors here, so we might as well > do a good job there.
If the kernel is going to make power choices automatically then it should do it everywhere, not piecemeal.
> > [...] This is going to be hugely more important on > > multi-socket systems, where your policy is usually going to be > > dictated by the specific workload that you're running at the > > time. [...] > > If only we had some kernel subsystem that is intimiately familar > with the workloads running on the system and could act > accordingly and with low latency. > > We could name that subsystem it in some intuitive fashion: it > switches and schedules workloads, so how about calling it the > 'scheduler'?
The scheduler is unaware of whether I care about a process finishing quickly or whether I care about it consuming less power.
> > [...] The exception is in cases where your rack is > > overcommitted for power and your rack management unit is > > telling you to reduce power consumption since otherwise it's > > going to have to cut the power to one of the machines in the > > rack in the next few seconds. > > ( That must be some ACPI middleware driven crap, right? Not > really the Linux kernel's problem. )
It's as much the Linux kernel's problem as AC/battery decisions are - ie, it's not.
> > > The thing is, when I use Linux on a laptop then AC/battery > > > is *the* main policy input. > > > > And it's already well handled from userspace, as it has to be. > > Not according to the developers switching away from Linux > desktop distros in droves, because MacOSX or Win7 has 30%+ > better battery efficiency.
Ok so what you're actually telling me here is that you don't understand anything about power management and where our problems are.
> The scheduler might be a small part of the picture, but it's > certainly a part of it.
It's in the drivers, which is where it has been since we went tickless.
> > No, because sched_mt_powersave usually crippled performance > > more than it saved power and nobody makes multi-socket > > laptops. > > That's a user-space policy management fail right there: why > wasn't this fixed? If the default policy is in the kernel we can > at least fix it in one place for the most common cases. If it's > spread out amongst multiple projects then progress only happens > at glacial speed ...
sched_mt_powersave was inherently going to have a huge impact on performance, and with modern chips that would result in the platform consuming more power. It was a feature that was useful for a small number of generations of desktop CPUs - I don't think it would ever skew the power/performance ratio in a useful direction on mobile hardware. But feel free to blame userspace for hardware design.
-- Matthew Garrett | mjg59@srcf.ucam.org
| |