On Tue, Aug 21, 2012 at 05:59:08PM +0200, Ingo Molnar wrote: > * Matthew Garrett <m...@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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
