> it's perfectly fine for a movie player to tell the power management
> daemon that it doesn't want the system to go to sleep, but the
> power management daemon may still decide to save power by shutting
> down the other 7 cores of an 8-core machine (or slow the clock down,
> but not so much that the app maxes out the remaining processing time)
Well, if you're using an Intel system, the unused cores will be clocked slower by the firmware running on them. cpufreq also has a role, and a bigger role on ARM. I don't think userspace daemons come into play at all here.
Your talk about "slowing the clock down" definitely seems like something that would screw up my movie playback. Even ignoring that issue, what if your externally imposed policy slows down other daemons that the movie player needs to function efficiently? A lot of applications use D-BUS these days. It's pretty clear that messing with timings on the pulseaudio daemon will probably cause audio glitches and dropouts in my movie playing, even though you oh so kindly allowed the movie player to continue running. Or If the movie player is embedded in Firefox, and you decide to mess with that process, there could also be problems.
If application developers want to opt in to a lazy clock policy, that is fine. We should set up a system call that allows them to do that, and start making use of that. But it shouldn't be forced on developers who don't want it.
Incidentally, kernel developers get really mad when other folks pull the same kind of "for your own good" BS on them-- for example, when hard drives "optimize" by not actually flushing the writes out to disk when they're told to do so.
At the end of the day, if you take away the ability of stupid people to do stupid things, you also take away the ability of smart people to do smart things. We have enough application developers out there that we can afford to install the programs written by the smart ones and ignore or fix the rest.
> Android 'gets it right' only for the simple case of a single core
> system. for multiple cores the information of an app claiming "I
> don't want to sleep now" isn't enough
Wakelocks and cpufreq are two distinct systems with different roles.
In general, Android's approach is to allow the application to use as much CPU as it wants, but to have good monitoring tools that allow users to spot and de-install CPU hogs. However, you need certain capabilities to do things like take a wakelock.