From: Peter Zijlstra on
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > If current hardware can't cope, too friggin bad, get better hardware.
> >
> > But the truth is, all your OMAP phones really can deal with it.
>
> That's rubbish and you know it. We do software workarounds for hardware
> problems all the time ... try doing a git grep -i errata in arch x86, or
> imagine a USB subsystem that only supported sane standards conforming
> devices: that would have an almost zero intersect with the current USB
> device market.
>
> The job of the kernel is to accommodate hardware as best it can ...
> sometimes it might not be able to, but most of the time it does a pretty
> good job.

Sure, and if x86 could wake from S3 on a keypress/mouse movement etc..
you could use S3 as idle state.. not sure people would love the
wakeup-latency, but that's a QoS matter.

But if there simply are no suitable wakeup sources from an idle state
(S3 really is nothing more than a hardware idle state) then it might not
be suitable for transparent idle modes and no amount of software hackery
will solve that.

So what I'm saying is, if your hardware can't generate the needed wakeup
events, the auto-suspend stuff won't work either. If it can it can be
implemented as a regular idle mode.

> The facts are that C states and S states are different and are entered
> differently. For some omap hardware, the power consumption in the
> lowest C state (with all the ancillary power control) is the same as S3,
> that's fine, suspend from idle works as well as suspend to ram modulo
> bad apps. For quite a lot of MSM hardware, the lowest C state power
> consumption is quite a bit above S3.

Wth is MSM?

But really, why can't existing hardware get shipped with existing hacks,
and for future hardware that does behave we have a proper solution?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > Not using suspend is exactly the point. As Alan has argued, propagating
> > suspend blockers up into all regions of userspace will take much longer
> > than fixing the hardware.
>
> Strange, that's not what I heard as the possible solution.

<20100527232043.784d5c72(a)lxorguk.ukuu.org.uk>
<20100528101755.7b5f6b8a(a)lxorguk.ukuu.org.uk>



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on
On Sat, 29 May 2010 20:12:14 +0200
Peter Zijlstra <peterz(a)infradead.org> wrote:

> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> >
> > Look, this is getting into the realms of a pointless semantic quibble.
> > The problem is that untrusted tasks need to be forcibly suspended when
> > they have no legitimate work to do and the user hasn't authorised them
> > to continue even if the scheduler sees them as runnable. Whether that's
> > achieved by suspending the entire system or forcibly idling the tasks
> > (using blocking states or freezers or something) so the scheduler can
> > suspend from idle is something to be discussed,
>
> So what happens if you task is CPU bound and gets suspended and is
> holding a resource (lock, whatever) that is required by someone else
> that didn't get suspended?
>
> That's the classic inversion problem, and is caused by not running
> runnable tasks.

The trick with the approach currently discussed (i.e.
opportunistic suspend, if you missed it): We suspend the whole machine.

And I really think, this is the only way to do it. It is a big hammer,
shure. But if you can pull it of...

>
> > but the net result is
> > that we have to stop a certain set of tasks in such a way that they can
> > still receive certain external events ... semantically, this is
> > equivalent to not running runnable tasks in my book.
>
> Why would be care about external events? Clearly these apps are ill
> behaved, otherwise they would have listened to the environment telling
> them to idle.
>
> Why would you try to let buggy apps work as intended instead of break
> them as hard as possible? Such policy promotes crappy code since people
> get away with it.

If I have a simple shell script then I don't wanna jump through
hoops just to please your fragile kernel.

And before you judge code that does not behave to work with YOUR buggy
kernel, i would think twice. This cuts both ways. Just because the
problem is too hard for you, this does not excuse forcing crappy
kernels on other people.

I think you have a point in that it is _in general_ not easily
possible to solve. But for this case this is clearly a simple, to the
point and working solution for android based phones.

"Der Wurm muss dem Fisch schmecken, nicht dem Angler."

>
> > (Perhaps this whole
> > thing is because the word runnable means different things ... I'm
> > thinking a task that would consume power ... are you thinking in the
> > scheduler R state?)
>
> Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.
>
> > Realistically, the main thing we need to do is stop timers posted
> > against the task (which is likely polling in a main loop, that being the
> > usual form of easy to write but power crazy app behaviour) from waking
> > the task and bringing the system out of suspend (whether from idle or
> > forced).
>
> Sure, that same main loop will probably receive a message along the
> lines of, 'hey, screen is off, we ought to go sleep'. If after that it
> doesn't listen, and more serious messages don't get responded to, simply
> kill the thing.

I think this would be a possibility. And maybe even sane. But I also
think this has nothing to do with suspend_blockers. They block
suspend. You know?

>
> Again, there is no reason what so ever to tolerate broken apps, it only
> promotes crappy apps.
>

This simple doesn't solve the problem.

Cheers,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on
On Mon, 31 May 2010 22:12:19 +0200
Florian Mickler <florian(a)mickler.org> wrote:

> On Sat, 29 May 2010 20:12:14 +0200
> Peter Zijlstra <peterz(a)infradead.org> wrote:
> >
> > Why would you try to let buggy apps work as intended instead of break
> > them as hard as possible? Such policy promotes crappy code since people
> > get away with it.
>
> If I have a simple shell script then I don't wanna jump through
> hoops just to please your fragile kernel.

Also why should that code on one device kill my uptime and on the
other machine (my wall-plugged desktop) work just well? That doesn't
sound right.

Clearly opportunistic suspend is a workaround for battery-driven devices
and no general solution. But it is not specific to android. At least
not inherently. It could be useful for any embedded or mobile device
where you can clearly distinguish important functions from convenience
functions.

I really can't understand the whole _fundamental_ opposition to this
design choice.

Cheers,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on
On Sat, 2010-05-29 at 20:12 +0200, Peter Zijlstra wrote:
> On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
> > > Correct, I strongly oppose using suspend. Not running runnable tasks is
> > > not a sane solution.
> >
> > Look, this is getting into the realms of a pointless semantic quibble.
> > The problem is that untrusted tasks need to be forcibly suspended when
> > they have no legitimate work to do and the user hasn't authorised them
> > to continue even if the scheduler sees them as runnable. Whether that's
> > achieved by suspending the entire system or forcibly idling the tasks
> > (using blocking states or freezers or something) so the scheduler can
> > suspend from idle is something to be discussed,
>
> So what happens if you task is CPU bound and gets suspended and is
> holding a resource (lock, whatever) that is required by someone else
> that didn't get suspended?
>
> That's the classic inversion problem, and is caused by not running
> runnable tasks.

OK ... but if the options are running and S3 for the entire platform,
then all tasks get suspended and this isn't a problem. This is why the
current wakelock implementation on the android platform works flawlessly
today.

Inversion only becomes a problem if tasks get individually idled, so you
can see that, from the android point of view, we're creating a problem
which their implementation doesn't have.

In this view, S3 suspend does look elegant: it solves the inversion
problem by suspending everything, it controls rogue applications' power
consumption and it gets certain hardware into a lower power state than
is possible from suspend from idle.

The inelegance of the S3 suspend solution is the requirement to use
these suspend blockers through kernel and user space to get the whole
thing up again to respond to an event, which is an inelegance suspend
from idle doesn't have.

> > but the net result is
> > that we have to stop a certain set of tasks in such a way that they can
> > still receive certain external events ... semantically, this is
> > equivalent to not running runnable tasks in my book.
>
> Why would be care about external events? Clearly these apps are ill
> behaved, otherwise they would have listened to the environment telling
> them to idle.

That's not a correct characterisation. Badly behaved apps from a power
point of view can do useful things for the user. The object is to
contain the badness while still getting useful stuff done.

> Why would you try to let buggy apps work as intended instead of break
> them as hard as possible? Such policy promotes crappy code since people
> get away with it.
>
> > (Perhaps this whole
> > thing is because the word runnable means different things ... I'm
> > thinking a task that would consume power ... are you thinking in the
> > scheduler R state?)
>
> Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.
>
> > Realistically, the main thing we need to do is stop timers posted
> > against the task (which is likely polling in a main loop, that being the
> > usual form of easy to write but power crazy app behaviour) from waking
> > the task and bringing the system out of suspend (whether from idle or
> > forced).
>
> Sure, that same main loop will probably receive a message along the
> lines of, 'hey, screen is off, we ought to go sleep'. If after that it
> doesn't listen, and more serious messages don't get responded to, simply
> kill the thing.
>
> Again, there is no reason what so ever to tolerate broken apps, it only
> promotes crappy apps.

Actually, no, if this were a correct view, we wouldn't have the huge x86
hardware work around problem because we'd just be able to tell
manufacturers of shoddy or badly standards compliant stuff where to
stick it.

The great strength of the x86 commodity platform revolution was the fact
that the hardware became cheap, plentiful and outside the ambit of a
single walled garden manufacturer. It's great weakness is integration
problems and shoddy hardware. We tolerate the weakness because the
strength vastly outweighs it: and toleration to us in the kernel means
driver work arounds ... it also means that if a device doesn't work with
the kernel, we get blamed (rather than the manufacturer).

By the same token, the revolution in smart phones is driven in quite a
large part by the provision of third party applications. This commodity
app view is almost the direct software analogue of the commodity
platform view that has been so successful in hardware; Therefore, fair
play seems to demand that we don't draw a hard line for software
applications that we wouldn't draw for hardware devices.

James


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