Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote:
> On Sat, 29 May 2010 00:11:32 +0200
> "Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
> 
> > 
> > Having reconsidered the suspend blockers idea I came to the conclusion that
> > in fact it was a workaround for three different problems.
> 
> But it is also a change of paradigm. The scheduler should strive to
> have the system idle as long as possible to conserve battery. And
> everything that does not serve the purpose of the device has to be
> considered as not worth running, except if there are other
> purpose-fullfilling tasks to run anyway.

No the purpose of the scheduler is to run tasks when they are runnable.
Not to second guess whatever caused them to become runnable.

If you start to randomly not run tasks, the inversion chaos that ensues
is terrible. You can apply the regular means of alleviating that and
that entails adding *-inheritance to all blockable resources. The -rt
patch set is doing that in part.

You really need to make applications not want to run and block on their
own volition (in a resource free point) and otherwise make them block on
something forcefully and disregard any malfunctioning that would result
from that, and in extreme cases terminate (releasing all resources).

But really Android shouldn't even need kernel support to do all this,
since its hosted on this massive middle-ware that intercepts everything,
called a Java Virtual Machine.

Now, all I'm interested in is providing interfaces from the kernel where
needed, so that userspace can be optimally frugal with power usage, and
can monitor/contain badly behaving tasks.

If Android is so set in its ways that they don't want to adopt (like
saying Android requires suspend for power management) then they can go
their own merry way and I'm not interested anymore (it would be a shame
though).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/