2010/5/31 Rafael J. Wysocki <[email protected]>:
> On Monday 31 May 2010, Arve Hj?nnev?g wrote:
>> 2010/5/30 Rafael J. Wysocki <[email protected]>:
> ...
>>
>> I think it makes more sense to block suspend while wakeup events are
>> pending than blocking it everywhere timers are used by code that could
>> be called while handling wakeup events or other critical work. Also,
>> even if you did block suspend everywhere timers where used you still
>> have the race where a wakeup interrupt happens right after you decided
>> to suspend. In other words, you still need to block suspend in all the
>> same places as with the current opportunistic suspend code, so what is
>> the benefit of delaying suspend until idle?
>
> Assume for a while that you don't use suspend blockers, OK? ?I realize you
> think that anything else doesn't make sense, but evidently some other people
> have that opinion about suspend blockers.
>
It sounded like you were suggesting that initiating suspend from idle
would somehow avoid the race condition with wakeup events. All I'm
saying is that you would need to block suspend in all the same places.
If you don't care about ignoring wakeup events, then sure you can
initiate suspend from idle.
> Now, under that assumption, I think it _generally_ is reasonable to make the
> system go into full suspend if everything (ie. CPUs and I/O) has been idle
> for sufficiently long time and there are no QoS requirements that aren't
> compatible with full system suspend.
>
--
Arve Hj?nnev?g
Hi,
ext Arve Hj?nnev?g wrote:
> It sounded like you were suggesting that initiating suspend from idle
> would somehow avoid the race condition with wakeup events. All I'm
> saying is that you would need to block suspend in all the same places.
> If you don't care about ignoring wakeup events, then sure you can
> initiate suspend from idle.
>
Sorry if i'm asking something that was already said, but the thread is
quite complex and i am not sure i have been able to grasp all of it.
So, regardless of the SW implementation:
-1) are you focusing on "good" HW or do you want to address all at the
same time?
-2) would you be ok with addressing "bad" HW as a special case, which
requires workarounds and shouldn't dictate the overall design?
-3) do you agree with the assumption that new HW is expected to get
reasonably better and therefore workarounds at point 2) will
progressively be confined to devices less and less common?
-4) going to the definition of "good" and "bad" (maybe this should have
come earlier in the list), can we define "good" HW as HW where:
* suspend state and lowest achievable runtime idle state are basically
equivalent from both power consumption and latency pov
* the HW itself is properly able to track wakeup sources while it is in
its deepest power state (as example OMAP3 has few independent
wake-capable pads and a "wake ring" where one only gets the information
that at least one of the pads belonging to such ring has received a wakeup)
* wakeup sources can be dynamically masked at HW level, so that if a
peripheral is not interesting, it doesn't wakeup the system (for example
the camera button when the camera cover is closed)
-5) HW that is not capable of properly generating asynchronous signal is
most likely the cause for extra timers in kernel and it should be
considered "bad" - in any other case having recurring in-kernel timers
should be treated as bugs, if their existence is not tied to some
meaningful work
thanks, igor
On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
> 2010/5/31 Rafael J. Wysocki <[email protected]>:
> > On Monday 31 May 2010, Arve Hj?nnev?g wrote:
> >> 2010/5/30 Rafael J. Wysocki <[email protected]>:
> > ...
> >>
> >> I think it makes more sense to block suspend while wakeup events are
> >> pending than blocking it everywhere timers are used by code that could
> >> be called while handling wakeup events or other critical work. Also,
> >> even if you did block suspend everywhere timers where used you still
> >> have the race where a wakeup interrupt happens right after you decided
> >> to suspend. In other words, you still need to block suspend in all the
> >> same places as with the current opportunistic suspend code, so what is
> >> the benefit of delaying suspend until idle?
> >
> > Assume for a while that you don't use suspend blockers, OK? ?I realize you
> > think that anything else doesn't make sense, but evidently some other people
> > have that opinion about suspend blockers.
> >
>
> It sounded like you were suggesting that initiating suspend from idle
> would somehow avoid the race condition with wakeup events. All I'm
> saying is that you would need to block suspend in all the same places.
> If you don't care about ignoring wakeup events, then sure you can
> initiate suspend from idle.
And why should you miss a wakeup there ? If you get an interrupt in
the transition, then you are not longer idle.
Thanks,
tglx
2010/6/1 Thomas Gleixner <[email protected]>:
> On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
>
>> 2010/5/31 Rafael J. Wysocki <[email protected]>:
>> > On Monday 31 May 2010, Arve Hj?nnev?g wrote:
>> >> 2010/5/30 Rafael J. Wysocki <[email protected]>:
>> > ...
>> >>
>> >> I think it makes more sense to block suspend while wakeup events are
>> >> pending than blocking it everywhere timers are used by code that could
>> >> be called while handling wakeup events or other critical work. Also,
>> >> even if you did block suspend everywhere timers where used you still
>> >> have the race where a wakeup interrupt happens right after you decided
>> >> to suspend. In other words, you still need to block suspend in all the
>> >> same places as with the current opportunistic suspend code, so what is
>> >> the benefit of delaying suspend until idle?
>> >
>> > Assume for a while that you don't use suspend blockers, OK? ?I realize you
>> > think that anything else doesn't make sense, but evidently some other people
>> > have that opinion about suspend blockers.
>> >
>>
>> It sounded like you were suggesting that initiating suspend from idle
>> would somehow avoid the race condition with wakeup events. All I'm
>> saying is that you would need to block suspend in all the same places.
>> If you don't care about ignoring wakeup events, then sure you can
>> initiate suspend from idle.
>
> And why should you miss a wakeup there ? If you get an interrupt in
> the transition, then you are not longer idle.
>
Because suspend itself causes you to not be idle you cannot abort
suspend just because you are not idle anymore.
--
Arve Hj?nnev?g
On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
> 2010/6/1 Thomas Gleixner <[email protected]>:
> > On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
> >
> >> 2010/5/31 Rafael J. Wysocki <[email protected]>:
> >> > On Monday 31 May 2010, Arve Hj?nnev?g wrote:
> >> >> 2010/5/30 Rafael J. Wysocki <[email protected]>:
> >> > ...
> >> >>
> >> >> I think it makes more sense to block suspend while wakeup events are
> >> >> pending than blocking it everywhere timers are used by code that could
> >> >> be called while handling wakeup events or other critical work. Also,
> >> >> even if you did block suspend everywhere timers where used you still
> >> >> have the race where a wakeup interrupt happens right after you decided
> >> >> to suspend. In other words, you still need to block suspend in all the
> >> >> same places as with the current opportunistic suspend code, so what is
> >> >> the benefit of delaying suspend until idle?
> >> >
> >> > Assume for a while that you don't use suspend blockers, OK? ?I realize you
> >> > think that anything else doesn't make sense, but evidently some other people
> >> > have that opinion about suspend blockers.
> >> >
> >>
> >> It sounded like you were suggesting that initiating suspend from idle
> >> would somehow avoid the race condition with wakeup events. All I'm
> >> saying is that you would need to block suspend in all the same places.
> >> If you don't care about ignoring wakeup events, then sure you can
> >> initiate suspend from idle.
> >
> > And why should you miss a wakeup there ? If you get an interrupt in
> > the transition, then you are not longer idle.
> >
>
> Because suspend itself causes you to not be idle you cannot abort
> suspend just because you are not idle anymore.
You still are addicted to the current suspend mechanism. :)
The whole point of doing it from idle in the form of a deep power
state is to avoid the massive sh*tload of work which is neccesary to
run the existing suspend code. But that needs runtime power management
and tweaks to avoid your timers waking you, etc.
The mechanism you want to use is: suspend no matter what, like closing
the lid of the laptop, but with a few tweaks around it:
1) An interrupt on a wakeup source which comes in while the suspend
code runs, i.e before you transitioned into wakeup mode, must
abort / prevent suspend.
2) Prevent another attempt to suspend before the event has been
delivered and the apps have signaled that they have not longer
any work to do.
As a side effect you confine crappy apps with that mechanism in
some way.
In the laptop case we do not want the tweaks as not going into suspend
might set your backpack on fire.
If I understood you correctly then you can shutdown the CPU in idle
completelty already, but that's not enough due to:
1) crappy applications keeping the cpu away from idle
2) timers firing
Would solving those two issues be sufficient for you or am I missing
something ?
Thanks,
tglx
2010/6/2 Thomas Gleixner <[email protected]>:
> On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
>> 2010/6/1 Thomas Gleixner <[email protected]>:
>> > On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
>> >
>> >> 2010/5/31 Rafael J. Wysocki <[email protected]>:
>> >> > On Monday 31 May 2010, Arve Hj?nnev?g wrote:
>> >> >> 2010/5/30 Rafael J. Wysocki <[email protected]>:
>> >> > ...
>> >> >>
>> >> >> I think it makes more sense to block suspend while wakeup events are
>> >> >> pending than blocking it everywhere timers are used by code that could
>> >> >> be called while handling wakeup events or other critical work. Also,
>> >> >> even if you did block suspend everywhere timers where used you still
>> >> >> have the race where a wakeup interrupt happens right after you decided
>> >> >> to suspend. In other words, you still need to block suspend in all the
>> >> >> same places as with the current opportunistic suspend code, so what is
>> >> >> the benefit of delaying suspend until idle?
>> >> >
>> >> > Assume for a while that you don't use suspend blockers, OK? ?I realize you
>> >> > think that anything else doesn't make sense, but evidently some other people
>> >> > have that opinion about suspend blockers.
>> >> >
>> >>
>> >> It sounded like you were suggesting that initiating suspend from idle
>> >> would somehow avoid the race condition with wakeup events. All I'm
>> >> saying is that you would need to block suspend in all the same places.
>> >> If you don't care about ignoring wakeup events, then sure you can
>> >> initiate suspend from idle.
>> >
>> > And why should you miss a wakeup there ? If you get an interrupt in
>> > the transition, then you are not longer idle.
>> >
>>
>> Because suspend itself causes you to not be idle you cannot abort
>> suspend just because you are not idle anymore.
>
> You still are addicted to the current suspend mechanism. :)
>
No I want you to stop confusing low power idle modes with suspend. I
know how to enter low power modes from idle if that low power mode is
not too disruptive.
> The whole point of doing it from idle in the form of a deep power
> state is to avoid the massive sh*tload of work which is neccesary to
> run the existing suspend code. But that needs runtime power management
> and tweaks to avoid your timers waking you, etc.
>
> The mechanism you want to use is: suspend no matter what, like closing
> the lid of the laptop, but with a few tweaks around it:
>
> ? 1) An interrupt on a wakeup source which comes in while the suspend
> ? ? ?code runs, i.e before you transitioned into wakeup mode, must
> ? ? ?abort / prevent suspend.
>
> ? 2) Prevent another attempt to suspend before the event has been
> ? ? ?delivered and the apps have signaled that they have not longer
> ? ? ?any work to do.
>
> ? As a side effect you confine crappy apps with that mechanism in
> ? some way.
>
> In the laptop case we do not want the tweaks as not going into suspend
> might set your backpack on fire.
If that is the case you should also disable the wakeup events.
>
> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
>
> ? ?1) crappy applications keeping the cpu away from idle
> ? ?2) timers firing
>
> Would solving those two issues be sufficient for you or am I missing
> something ?
Solving those two is enough for current android phones, but it may not
be enough for other android devices. 1 is not solvable (meaning we
cannot fix all apps), and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way
to solve 2 is to allow timers on a not-idle clock. Unrelated to
Android, I also want to use opportunistic suspend on my desktop.
--
Arve Hj?nnev?g
On Wed, 2 Jun 2010, Arve Hj?nnev?g wrote:
> 2010/6/2 Thomas Gleixner <[email protected]>:
> > On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
> >>
> >> Because suspend itself causes you to not be idle you cannot abort
> >> suspend just because you are not idle anymore.
> >
> > You still are addicted to the current suspend mechanism. :)
> >
>
> No I want you to stop confusing low power idle modes with suspend. I
> know how to enter low power modes from idle if that low power mode is
> not too disruptive.
What prevents us from going into a disruptive mode from idle ? I don't
see a reason - except crappy ACPI stuff, which I'm happy to ignore.
> > If I understood you correctly then you can shutdown the CPU in idle
> > completelty already, but that's not enough due to:
> >
> > ? ?1) crappy applications keeping the cpu away from idle
> > ? ?2) timers firing
> >
> > Would solving those two issues be sufficient for you or am I missing
> > something ?
>
> Solving those two is enough for current android phones, but it may not
> be enough for other android devices.
In which way ? May not be enough is a pretty vague statement.
> 1 is not solvable (meaning we cannot fix all apps),
We can mitigate it with cgroups and confine crap there, i.e. force
idle them.
> and 2 is difficult to fix since the periodic
> work is useful while the device is actually in use. One possible way
> to solve 2 is to allow timers on a not-idle clock.
That's what I had in mind.
> Unrelated to Android, I also want to use opportunistic suspend on my
> desktop.
I expect that intel/amd fixing their stuff is going to happen way
before we sprinkled suspend blockers over a full featured desktop
distro.
Thanks,
tglx
On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
> If I understood you correctly then you can shutdown the CPU in idle
> completelty already, but that's not enough due to:
>
> 1) crappy applications keeping the cpu away from idle
> 2) timers firing
>
> Would solving those two issues be sufficient for you or am I missing
> something ?
Aren't the container snapshot/resume people fighting the same set of
problems here?
2010/6/2 Thomas Gleixner <[email protected]>:
> On Wed, 2 Jun 2010, Arve Hj?nnev?g wrote:
>> 2010/6/2 Thomas Gleixner <[email protected]>:
>> > On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
>> >>
>> >> Because suspend itself causes you to not be idle you cannot abort
>> >> suspend just because you are not idle anymore.
>> >
>> > You still are addicted to the current suspend mechanism. :)
>> >
>>
>> No I want you to stop confusing low power idle modes with suspend. I
>> know how to enter low power modes from idle if that low power mode is
>> not too disruptive.
>
> What prevents us from going into a disruptive mode from idle ? I don't
> see a reason - except crappy ACPI stuff, which I'm happy to ignore.
>
What do you consider disruptive? Disabling active interrupts? Stopping
the monotonic clock?
>> > If I understood you correctly then you can shutdown the CPU in idle
>> > completelty already, but that's not enough due to:
>> >
>> > ? ?1) crappy applications keeping the cpu away from idle
>> > ? ?2) timers firing
>> >
>> > Would solving those two issues be sufficient for you or am I missing
>> > something ?
>>
>> Solving those two is enough for current android phones, but it may not
>> be enough for other android devices.
>
> In which way ? May not be enough is a pretty vague statement.
They may not be based on hardware that can get to the same power mode
from idle as suspend. This could be acpi based hardware, it could be
like the hardware we started with that did not have regular timers
that could run in the low power mode, or devices could loose their
state in the lowest power mode.
>
>> 1 is not solvable (meaning we cannot fix all apps),
>
> We can mitigate it with cgroups and confine crap there, i.e. force
> idle them.
>
I think using suspend is much simpler. It avoids having to worry about
dependencies between processes.
>> and 2 is difficult to fix since the periodic
>> work is useful while the device is actually in use. One possible way
>> to solve 2 is to allow timers on a not-idle clock.
>
> That's what I had in mind.
>
>> Unrelated to Android, I also want to use opportunistic suspend on my
>> desktop.
>
> I expect that intel/amd fixing their stuff is going to happen way
> before we sprinkled suspend blockers over a full featured desktop
> distro.
>
You do not need to sprinkle suspend blocker all over the distro for it
to be useful. You can convert the existing auto-suspend code to use
opportunistic suspend and all apps that don't use suspend blocker will
behave as they do today while allowing apps to use suspend blockers to
keep the system running after the auto-suspend timeout expired.
--
Arve Hj?nnev?g
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> No I want you to stop confusing low power idle modes with suspend.
I think it is you who is confused. For power management purposes suspend
is nothing more but a deep idle state.
(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
fixing it, get over it already).
> Unrelated to
> Android, I also want to use opportunistic suspend on my desktop.
So you're going to sprinkle this suspend blocker shite all over regular
userspace? Why not instead work on getting apps to behave properly and
idle when there's nothing to do?
After all, if you have the code to add suspend blockers into, you also
have the means to fix it being stupid in the first place.
2010/6/2 Peter Zijlstra <[email protected]>:
> On Wed, 2010-06-02 at 01:54 -0700, Arve Hj?nnev?g wrote:
>> No I want you to stop confusing low power idle modes with suspend.
>
> I think it is you who is confused. For power management purposes suspend
> is nothing more but a deep idle state.
No, idle is transparent, suspend is not.
>
> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> fixing it, get over it already).
>
I don't think it is realistic to drop support for all existing hardware.
>> Unrelated to
>> Android, I also want to use opportunistic suspend on my desktop.
>
> So you're going to sprinkle this suspend blocker shite all over regular
> userspace?
I have said several times, that regular user-space will not need to be
modified to maintain their current behavior.
> Why not instead work on getting apps to behave properly and
> idle when there's nothing to do?
>
> After all, if you have the code to add suspend blockers into, you also
> have the means to fix it being stupid in the first place.
>
Why would I add suspend blockers to the code I want to prevent running?
--
Arve Hj?nnev?g
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote:
> 2010/6/2 Peter Zijlstra <[email protected]>:
> > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
> >> No I want you to stop confusing low power idle modes with suspend.
> >
> > I think it is you who is confused. For power management purposes suspend
> > is nothing more but a deep idle state.
>
> No, idle is transparent, suspend is not.
Which is where the problem is, it should be.
> Why would I add suspend blockers to the code I want to prevent running?
Because what you want might not be what others want. Suppose you're fine
with your torrent client/irc client/etc.. to loose their network
connection when you're not behind your desktop so you don't add suspend
blockers there.
Me, I'd be ready to administer physical violence if either of those lost
their connections when I wasn't around to keep the screen-saver from
kicking in.
This leads to having to sprinkle magic dust (and lots of config options)
all over userspace. Something that gets esp interesting with only a
boolean interface.
In the example above, having an active net connection would prevent my
desktop from suspending, but what if another platform can maintain net
connections while suspended? Do we then end up with arch specific code
in the net-stack? I'm sure DaveM would love that.
On Wed, 02 Jun 2010 11:10:51 +0200
Peter Zijlstra <[email protected]> wrote:
> On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
>
>
> > If I understood you correctly then you can shutdown the CPU in idle
> > completelty already, but that's not enough due to:
> >
> > 1) crappy applications keeping the cpu away from idle
> > 2) timers firing
> >
> > Would solving those two issues be sufficient for you or am I missing
> > something ?
>
> Aren't the container snapshot/resume people fighting the same set of
> problems here?
And virtualisation - its a big one for virtualisation because if you've
got 1000 misbehaving guests generating 100 wakeups a second you've got a
problem ....
Alan
On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra <[email protected]> wrote:
> On Wed, 2010-06-02 at 03:00 -0700, Arve Hj?nnev?g wrote:
> > 2010/6/2 Peter Zijlstra <[email protected]>:
> > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hj?nnev?g wrote:
> > >> No I want you to stop confusing low power idle modes with suspend.
> > >
> > > I think it is you who is confused. For power management purposes suspend
> > > is nothing more but a deep idle state.
> >
> > No, idle is transparent, suspend is not.
>
> Which is where the problem is, it should be.
>
> > Why would I add suspend blockers to the code I want to prevent running?
>
> Because what you want might not be what others want. Suppose you're fine
> with your torrent client/irc client/etc.. to loose their network
> connection when you're not behind your desktop so you don't add suspend
> blockers there.
>
> Me, I'd be ready to administer physical violence if either of those lost
> their connections when I wasn't around to keep the screen-saver from
> kicking in.
Do you switch your pc on and off manually? Sometimes? Really?
(if not, you are probably a kernel hacker *g*)
I assume, in general, there are only a few reasons to shut down a
machine:
1. One has to do maintainance on the hardware or somehow needs to
interrupt the power supply.
2. One wants to save power.
3. One wants to go easy on the hardware.
4. ...?
Obviously, for reason 1 we need to maintain the shutdown-paths
indefinitely.
But the rest are usecases that are similar to the suspend-blocker
usecases. You know that you are not using the machine and going
through the pain to shut down your machine. You have to do it manually.
Why?
> This leads to having to sprinkle magic dust (and lots of config options)
> all over userspace. Something that gets esp interesting with only a
> boolean interface.
A userspace daemon could keep track of what applications can be
ignored. The wordprocessor probably should not keep the system busy. As
well as a running firefox.
It is a hard problem. But we have _no way of deciding any of this in
the kernel_!
>
> In the example above, having an active net connection would prevent my
> desktop from suspending, but what if another platform can maintain net
> connections while suspended? Do we then end up with arch specific code
> in the net-stack? I'm sure DaveM would love that.
>
If it is driver knowledge, then it goes into the driver.
If it is platform knowledge, then it goes into the platform code.
I think that is a clear requirement to keeping sanity.
The problem is there independently of suspend blockers. If the system
can suspend with network up, then you shure as hell want to suspend
even if the network is up. So it would actually be a reason for any
kind of "suspend blockers" scheme. Wouldn't it?
Cheers,
Flo
On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote:
> On Wed, 02 Jun 2010 12:21:28 +0200
> Peter Zijlstra <[email protected]> wrote:
> Do you switch your pc on and off manually? Sometimes? Really?
> (if not, you are probably a kernel hacker *g*)
Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace
parts, but no, not otherwise ;-) But I've been doing that for pretty
much as long as I've had a computer.
> But the rest are usecases that are similar to the suspend-blocker
> usecases. You know that you are not using the machine and going
> through the pain to shut down your machine. You have to do it manually.
> Why?
Make suspend an idle state and teach apps to go real quiet.
(Then again, that only really works when regular network packets can
wake the machine for my case).
> > This leads to having to sprinkle magic dust (and lots of config options)
> > all over userspace. Something that gets esp interesting with only a
> > boolean interface.
>
> A userspace daemon could keep track of what applications can be
> ignored. The wordprocessor probably should not keep the system busy. As
> well as a running firefox.
>
> It is a hard problem. But we have _no way of deciding any of this in
> the kernel_
Therefore I say, fix the worprocessor to not actually do anything if its
not poked at -- not too hard, wordprocessors really don't need to do
anything on their own, and you can do your last backup cycle when the
window becomes invisible and stop the timer until the document changes
again.
Same for firefox, you can teach it to not render animated gifs and run
javascript for invisible tabs, and once the screen-saver kicks in,
nothing is visible (and with X telling apps their window is visible or
not it knows), so it should go idle all of its own.
Fix the friggin apps, don't kludge with freezing.
You really only ever want to freeze broken apps. And even for those I
would prefer it if I got notified some app is stupid, then I could
either fix it, or choose not to use it.
You can also teach cron to listen to dbus messages telling it about the
screen state and postpone jobs -- but please make that a configurable
thing, I really like all that work done at 4am when I'm (usually) not
around to be bothered by it.
> The problem is there independently of suspend blockers. If the system
> can suspend with network up, then you shure as hell want to suspend
> even if the network is up. So it would actually be a reason for any
> kind of "suspend blockers" scheme. Wouldn't it?
Well, at that point suspend is nothing more than an idle state, and
platform code needs to somehow inform the idle state governor that
active net connections need to prevent that idle state from being used.
If you want to call that suspend blockers, then sure, but its a long way
away from the explicit scheme proposed at the start of this thread.
On Thu, 03 Jun 2010 09:40:02 +0200
Peter Zijlstra <[email protected]> wrote:
> Same for firefox, you can teach it to not render animated gifs and run
> javascript for invisible tabs, and once the screen-saver kicks in,
> nothing is visible (and with X telling apps their window is visible or
> not it knows), so it should go idle all of its own.
>
> Fix the friggin apps, don't kludge with freezing.
Of course programs should be as smart as possible. But that is an
orthogonal problem.
Suppose firefox were fixed. It still needs to fetch my rss feeds every
minute, because I'm sad if it doesn't. It just can't be fixed at the
application level.
Cheers,
Flo
On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> On Thu, 03 Jun 2010 09:40:02 +0200
> Peter Zijlstra <[email protected]> wrote:
>
> > Same for firefox, you can teach it to not render animated gifs and run
> > javascript for invisible tabs, and once the screen-saver kicks in,
> > nothing is visible (and with X telling apps their window is visible or
> > not it knows), so it should go idle all of its own.
> >
> > Fix the friggin apps, don't kludge with freezing.
>
> Of course programs should be as smart as possible. But that is an
> orthogonal problem.
>
> Suppose firefox were fixed. It still needs to fetch my rss feeds every
> minute, because I'm sad if it doesn't. It just can't be fixed at the
> application level.
Sure it can, why would it need to fetch RSS feeds when the screen is off
and nobody could possible see the result? So you can stop the timer when
you know the window isn't visible or alternatively when the screensaver
is active, I think most desktops have notification of that as well.
On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra <[email protected]> wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> > On Thu, 03 Jun 2010 09:40:02 +0200
> > Peter Zijlstra <[email protected]> wrote:
> >
> > > Same for firefox, you can teach it to not render animated gifs and run
> > > javascript for invisible tabs, and once the screen-saver kicks in,
> > > nothing is visible (and with X telling apps their window is visible or
> > > not it knows), so it should go idle all of its own.
> > >
> > > Fix the friggin apps, don't kludge with freezing.
> >
> > Of course programs should be as smart as possible. But that is an
> > orthogonal problem.
> >
> > Suppose firefox were fixed. It still needs to fetch my rss feeds every
> > minute, because I'm sad if it doesn't. It just can't be fixed at the
> > application level.
>
> Sure it can, why would it need to fetch RSS feeds when the screen is off
> and nobody could possible see the result? So you can stop the timer when
> you know the window isn't visible or alternatively when the screensaver
> is active, I think most desktops have notification of that as well.
This is arguing on a very thin line. In fact it is becoming pointless.
Suppose there were an RSS-feed plugin that signals events to an event
Plugin. That event plugin could be either visual notification or sending
audio-signals. But the RSS feed doesn't know what specific plugin it
talks to. So screen off is _not always_ the right indicator. Sometimes
it is, sometimes it's not.
There would be a seperate infrastructure needed in the program to tell
the different plugins that the core thinks everything should stop.
How does the core knows when to stop? And then there probably need to
be some kind of "suspend blockers" in the program. *g*
Just solve it at the right level, so that the apps don't need to be
infected with this shit. And this belongs between the iron and the
apps. And it seems it needs to be some cooperative approach of kernel
and userspace-framework as it isn't right to put that much policy in
the kernel.
I don't think it is a black and white thing, where you can just say
"fix the friggin apps".
And this is a really f*beep*ng serious point. (at least to me)
Cheers,
Flo
On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <[email protected]> wrote:
> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
>> On Thu, 03 Jun 2010 09:40:02 +0200
>> Peter Zijlstra <[email protected]> wrote:
>>
>> > Same for firefox, you can teach it to not render animated gifs and run
>> > javascript for invisible tabs, and once the screen-saver kicks in,
>> > nothing is visible (and with X telling apps their window is visible or
>> > not it knows), so it should go idle all of its own.
>> >
>> > Fix the friggin apps, don't kludge with freezing.
>>
>> Of course programs should be as smart as possible. But that is an
>> orthogonal problem.
>>
>> Suppose firefox were fixed. It still needs to fetch my rss feeds every
>> minute, because I'm sad if it doesn't. It just can't be fixed at the
>> application level.
>
> Sure it can, why would it need to fetch RSS feeds when the screen is off
> and nobody could possible see the result? So you can stop the timer when
> you know the window isn't visible or alternatively when the screensaver
> is active, I think most desktops have notification of that as well.
Exactly, and that's what applications in the N900 do. For this to work
reliably, you need these notifications (network disconnected, screen
off) to be easily accessible, and even transparent to the application
writer.
I don't think the suspend blockers solve much. A bad application will
behave bad on any system. Suppose somebody decides to port Firefox to
Android, and forgets to listen to the screen off event (bad on Android
or Maemo), however, notices the application behaves very badly, so by
googling finds these suspend blockers, and enables them all the time
the application runs.
When the user install the application, will be greeted by a warning
"This application might break PM, do you want to enable suspend
blockers?" (or whatever), as any typical user would do, will press Yes
(whatever).
We end up in exactly the same situation.
--
Felipe Contreras
2010/6/2 Arve Hjønnevåg <[email protected]>:
> 2010/6/2 Peter Zijlstra <[email protected]>:
>> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> fixing it, get over it already).
>>
>
> I don't think it is realistic to drop support for all existing hardware.
We are talking about mainline here, there's no support for suspend
blockers, so nothing is dropped.
In the mind of everybody, suspend blockers is for opportunistic
suspend, which only makes sense on sensible hw (not current x86). So
in the mind of everybody, x86 should be out of scope for the analysis
of suspend blockers.
Are you seriously suggesting that one of the strong arguments in favor
of suspend blockers is x86 usage (nobody agrees)? If not, then drop
it.
>>> Unrelated to
>>> Android, I also want to use opportunistic suspend on my desktop.
>>
>> So you're going to sprinkle this suspend blocker shite all over regular
>> userspace?
>
> I have said several times, that regular user-space will not need to be
> modified to maintain their current behavior.
If I enable suspend blockers on my laptop, I have to modify my
user-space. Otherwise my system will behave horribly.
--
Felipe Contreras
On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras <[email protected]> wrote:
> On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <[email protected]> wrote:
> > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> >> On Thu, 03 Jun 2010 09:40:02 +0200
> >> Peter Zijlstra <[email protected]> wrote:
> >>
> >> > Fix the friggin apps, don't kludge with freezing.
> >>
> >> Of course programs should be as smart as possible. But that is an
> >> orthogonal problem.
> >>
> >> Suppose firefox were fixed. It still needs to fetch my rss feeds every
> >> minute, because I'm sad if it doesn't. It just can't be fixed at the
> >> application level.
> >
> > Sure it can, why would it need to fetch RSS feeds when the screen is off
> > and nobody could possible see the result? So you can stop the timer when
> > you know the window isn't visible or alternatively when the screensaver
> > is active, I think most desktops have notification of that as well.
>
> Exactly, and that's what applications in the N900 do. For this to work
> reliably, you need these notifications (network disconnected, screen
> off) to be easily accessible, and even transparent to the application
> writer.
>
> I don't think the suspend blockers solve much. A bad application will
> behave bad on any system. Suppose somebody decides to port Firefox to
> Android, and forgets to listen to the screen off event (bad on Android
> or Maemo), however, notices the application behaves very badly, so by
> googling finds these suspend blockers, and enables them all the time
> the application runs.
>
> When the user install the application, will be greeted by a warning
> "This application might break PM, do you want to enable suspend
> blockers?" (or whatever), as any typical user would do, will press Yes
> (whatever).
>
> We end up in exactly the same situation.
>
No. The application will show up in the suspend blocker stats and the
user will remember: "Oh, yes. There was a warning about that. Well I
think I'm going to file a bug there."
The only difference is, that with suspend blockers, he can than
dismiss the applications permission to block suspend and will not miss
his job interview the next day because his phones battery run
out. And also he can use the application to a certain extent.
Cheers,
Flo
On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras <[email protected]> wrote:
> 2010/6/2 Arve Hj?nnev?g <[email protected]>:
> > 2010/6/2 Peter Zijlstra <[email protected]>:
> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
> >> fixing it, get over it already).
> >>
> >
> > I don't think it is realistic to drop support for all existing hardware.
>
> We are talking about mainline here, there's no support for suspend
> blockers, so nothing is dropped.
>
> In the mind of everybody, suspend blockers is for opportunistic
> suspend, which only makes sense on sensible hw (not current x86). So
> in the mind of everybody, x86 should be out of scope for the analysis
> of suspend blockers.
>
> Are you seriously suggesting that one of the strong arguments in favor
> of suspend blockers is x86 usage (nobody agrees)? If not, then drop
> it.
I think they have an advantage over the
30-minute-screensaver-then-suspend that current desktops do. Because
you can define what keeps the system up. I.e. the
screensaver/powermanager is not limited to keyboard- and
mouse-inactivity.
> If I enable suspend blockers on my laptop, I have to modify my
> user-space. Otherwise my system will behave horribly.
>
In the simplest case you have a shell script which takes a suspend
blocker and reads from stdinput. When you write "mem" to it, it
releases the suspend blocker and acquires it back again. Voila, forced
suspend reimplemented on top of opportunistic suspend.
That wasn't hard, was it?
Cheers,
Flo
On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <[email protected]> wrote:
> On Sat, 5 Jun 2010 20:30:40 +0300
> Felipe Contreras <[email protected]> wrote:
>> I don't think the suspend blockers solve much. A bad application will
>> behave bad on any system. Suppose somebody decides to port Firefox to
>> Android, and forgets to listen to the screen off event (bad on Android
>> or Maemo), however, notices the application behaves very badly, so by
>> googling finds these suspend blockers, and enables them all the time
>> the application runs.
>>
>> When the user install the application, will be greeted by a warning
>> "This application might break PM, do you want to enable suspend
>> blockers?" (or whatever), as any typical user would do, will press Yes
>> (whatever).
>>
>> We end up in exactly the same situation.
>>
> No. The application will show up in the suspend blocker stats and the
> user will remember: "Oh, yes. There was a warning about that. Well I
> think I'm going to file a bug there."
How would such stats be calculated? I presume at regular intervals you
check which applications are holding suspend blockers and increase a
counter.
How would you do that with the dynamic PM approach? At regular
intervals you check for which applications are running (not idle).
> The only difference is, that with suspend blockers, he can than
> dismiss the applications permission to block suspend and will not miss
> his job interview the next day because his phones battery run
> out. And also he can use the application to a certain extent.
So the difference is between removing the app, and making it run
crappy. I don't think that's a strong argument in favor of suspend
blockers.
--
Felipe Contreras
On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler <[email protected]> wrote:
> On Sat, 5 Jun 2010 20:44:24 +0300
> Felipe Contreras <[email protected]> wrote:
>
>> 2010/6/2 Arve Hjønnevåg <[email protected]>:
>> > 2010/6/2 Peter Zijlstra <[email protected]>:
>> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
>> >> fixing it, get over it already).
>> >>
>> >
>> > I don't think it is realistic to drop support for all existing hardware.
>>
>> We are talking about mainline here, there's no support for suspend
>> blockers, so nothing is dropped.
>>
>> In the mind of everybody, suspend blockers is for opportunistic
>> suspend, which only makes sense on sensible hw (not current x86). So
>> in the mind of everybody, x86 should be out of scope for the analysis
>> of suspend blockers.
>>
>> Are you seriously suggesting that one of the strong arguments in favor
>> of suspend blockers is x86 usage (nobody agrees)? If not, then drop
>> it.
>
> I think they have an advantage over the
> 30-minute-screensaver-then-suspend that current desktops do. Because
> you can define what keeps the system up. I.e. the
> screensaver/powermanager is not limited to keyboard- and
> mouse-inactivity.
What prevents you from defining other things keeping the system up
right now? Nothing. It's up to user-space to decide when to suspend.
In fact applications already block suspend; Transmission has the
option to block suspend when downloading torrents.
>> If I enable suspend blockers on my laptop, I have to modify my
>> user-space. Otherwise my system will behave horribly.
>>
>
> In the simplest case you have a shell script which takes a suspend
> blocker and reads from stdinput. When you write "mem" to it, it
> releases the suspend blocker and acquires it back again. Voila, forced
> suspend reimplemented on top of opportunistic suspend.
>
> That wasn't hard, was it?
Not hard, but still a modification of user-space, and a pretty bad one
because it will prevent typical forced suspend, and typical suspend
delaying (like with Transmission). Supposing the opportunistic suspend
doesn't block the forced suspend, still, absolutely nothing will be
achieved by enabling suspend blockers.
If you want to take even a minimal advantage of suspend blockers you
need serious modifications to user-space.
Supposing there's a perfect usage of suspend blockers from user-space
on current x86 platforms (in theory Android would have that), is the
benefit that big to consider this a strong argument in favor of
suspend blockers? Considering the small amount of x86 platforms using
Android (is there any?), the fact that nobody else will use suspend
blockers, and that x86 is already being fixed (as mentioned many times
before) so dynamic PM is possible, I don't think we should be
considering current x86 at all for suspend blockers.
--
Felipe Contreras
On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras <[email protected]> wrote:
> On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler <[email protected]> wrote:
> > On Sat, 5 Jun 2010 20:30:40 +0300
> > Felipe Contreras <[email protected]> wrote:
> >> I don't think the suspend blockers solve much. A bad application will
> >> behave bad on any system. Suppose somebody decides to port Firefox to
> >> Android, and forgets to listen to the screen off event (bad on Android
> >> or Maemo), however, notices the application behaves very badly, so by
> >> googling finds these suspend blockers, and enables them all the time
> >> the application runs.
> >>
> >> When the user install the application, will be greeted by a warning
> >> "This application might break PM, do you want to enable suspend
> >> blockers?" (or whatever), as any typical user would do, will press Yes
> >> (whatever).
> >>
> >> We end up in exactly the same situation.
> >>
> > No. The application will show up in the suspend blocker stats and the
> > user will remember: "Oh, yes. There was a warning about that. Well I
> > think I'm going to file a bug there."
>
> How would such stats be calculated? I presume at regular intervals you
> check which applications are holding suspend blockers and increase a
> counter.
>
> How would you do that with the dynamic PM approach? At regular
> intervals you check for which applications are running (not idle).
IIRC, the patches discussed have debugging infrastructure in
them. The kernel does the accounting.
>
> > The only difference is, that with suspend blockers, he can than
> > dismiss the applications permission to block suspend and will not miss
> > his job interview the next day because his phones battery run
> > out. And also he can use the application to a certain extent.
>
> So the difference is between removing the app, and making it run
> crappy. I don't think that's a strong argument in favor of suspend
> blockers.
>
If you think a little about it, it is. Because if the app wouldn't be
usable at all, the bug wouldn't get fixed because the user wouldn't use
it. Or not?
Cheers,
Flo
On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras <[email protected]> wrote:
> Supposing there's a perfect usage of suspend blockers from user-space
> on current x86 platforms (in theory Android would have that), is the
> benefit that big to consider this a strong argument in favor of
> suspend blockers? Considering the small amount of x86 platforms using
> Android (is there any?), the fact that nobody else will use suspend
> blockers, and that x86 is already being fixed (as mentioned many times
> before) so dynamic PM is possible, I don't think we should be
> considering current x86 at all for suspend blockers.
A solution for the desktop to deprecate having to shut down the
machine would not be that bad, wouldn;t it? (Why have I to shut down
my machine anyway?)
In my opinion such a decision (when to shutdown) has to be guided by
userspace knowledge.
Future x86 hardware is to be fixed (as I read in this discussion), so
using suspend blockers could be the tool of choice.
But alright. Let's be a little bit more focused on the present
situation:
1) There currently is no other solution.
2) It is a first stepping stone to bringing android to mainline.
3) Any "perfect" solution will emerge anyway. As there are so many
people with so strong opinions engaged in this discussion, I'm
confident.
4) If there is a better solution, android will shurely adapt it as
soon as it is there.
Cheers,
Flo
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:26:27 +0300
> Felipe Contreras <[email protected]> wrote:
>
> > Supposing there's a perfect usage of suspend blockers from user-space
> > on current x86 platforms (in theory Android would have that), is the
> > benefit that big to consider this a strong argument in favor of
> > suspend blockers? Considering the small amount of x86 platforms using
> > Android (is there any?), the fact that nobody else will use suspend
> > blockers, and that x86 is already being fixed (as mentioned many times
> > before) so dynamic PM is possible, I don't think we should be
> > considering current x86 at all for suspend blockers.
>
> A solution for the desktop to deprecate having to shut down the
> machine would not be that bad, wouldn;t it? (Why have I to shut down
> my machine anyway?)
>
> In my opinion such a decision (when to shutdown) has to be guided by
> userspace knowledge.
> Future x86 hardware is to be fixed (as I read in this discussion), so
> using suspend blockers could be the tool of choice.
>
> But alright. Let's be a little bit more focused on the present
> situation:
>
> 1) There currently is no other solution.
Wrong. The solutions are there, just being refused.
> 2) It is a first stepping stone to bringing android to mainline.
Crap. Once we have an userspace API we are bound to it. Period.
Also there is no technical reason why the whole driver stack cannot
be merged w/o the suspend blockers.
> 3) Any "perfect" solution will emerge anyway. As there are so many
> people with so strong opinions engaged in this discussion, I'm
> confident.
Yes, and that needs cooperation and compromises from both sides and
not just blindly defining that there is no other solution.
> 4) If there is a better solution, android will shurely adapt it as
> soon as it is there.
Sure, after we accepted the crap there is no incentive at all.
Stop that advertising campaing already.
No thanks,
tglx
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:
> Stop that advertising campaing already.
Stop advertising that there is no problem.
>
> No thanks,
>
> tglx
Cheers,
Flo
(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering and not dismissing the problem. This was pointed at
Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")
On Sat, 5 Jun 2010, Florian Mickler wrote:
> On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
> Thomas Gleixner <[email protected]> wrote:
>
> > Stop that advertising campaing already.
>
> Stop advertising that there is no problem.
>
> >
> > No thanks,
> >
> > tglx
>
> Cheers,
> Flo
>
> (Sorry, crossfire. Caused
> by you answering in the wrong subthread. I know that you are
> engineering and not dismissing the problem. This was pointed at
> Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")
Welcome to my killfile.
On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler <[email protected]> wrote:
> On Sat, 5 Jun 2010 23:06:03 +0300
> Felipe Contreras <[email protected]> wrote:
>> How would such stats be calculated? I presume at regular intervals you
>> check which applications are holding suspend blockers and increase a
>> counter.
>>
>> How would you do that with the dynamic PM approach? At regular
>> intervals you check for which applications are running (not idle).
>
> IIRC, the patches discussed have debugging infrastructure in
> them. The kernel does the accounting.
We are not talking about debugging, we are talking about stats shown
in user-space so that users can see the offending apps. It doesn't
matter where the accounting is done, it would be at regular intervals
and there's nothing that prevents the dynamic PM approach to offer
similar stats.
>> > The only difference is, that with suspend blockers, he can than
>> > dismiss the applications permission to block suspend and will not miss
>> > his job interview the next day because his phones battery run
>> > out. And also he can use the application to a certain extent.
>>
>> So the difference is between removing the app, and making it run
>> crappy. I don't think that's a strong argument in favor of suspend
>> blockers.
>>
> If you think a little about it, it is. Because if the app wouldn't be
> usable at all, the bug wouldn't get fixed because the user wouldn't use
> it. Or not?
I'm not sure what's your point here. One user not using a certain
application doesn't prevent bugs to get fixed. In fact, less people
using an app will cause less buzz, and less downloads, and less
positive votes... which might wake up the author to think: hey, maybe
I'm doing something wrong? Maybe I should really listen to those bug
reports.
Anyway, my point is that there's nothing special about 3rd party app
stats with suspend blockers.
--
Felipe Contreras