Re: Attempted summary of suspend-blockers LKML thread, take three

[Felipe Contreras]

On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>> You may also wish to review the earlier parts of the discussion where it
>> was explicitly stated by several developers that they were using
>> "suspend" type modes as power states already and not using suspend
>> blockers. So it's being done, today on ARM and your statement is directly
>> contradicting the code. Modern ARM processors and x86 MID devices can
>> suspend and resume extremely fast (fast enough that the fact Linux x86
>> rewriting all the SMP alternatives on suspend/resume is a measurable
>> problem). If this same property doesn't end up on big PC boxes in time
>> then I'd be very surprised. At that point the openoffice with suspend
>> blockers or oracle with suspend blockers question becomes rather relevant.
>
> Here is the list of properties distinguishing idle from suspend:
>
> 1. Â Â ÂIdle states are entered by a given CPU only there are no runnable
> Â Â Â Âtasks for that CPU. ÂIn contrast, opportunistic suspend can
> Â Â Â Âhalt the entire system even when there are tasks that are ready,
> Â Â Â Âwilling, and able to run. Â(But please note that this might not
> Â Â Â Âapply to real-time tasks.)

But if there are no runnable tasks (which is the target), they behave the same.

> 2. Â Â ÂThere can be a set of input events that do not bring the system
> Â Â Â Âout of suspend, but which would bring the system out of idle.
> Â Â Â ÂExactly which events are in this set depends both on hardware
> Â Â Â Âcapabilities and on the platform/application policy. ÂFor example,
> Â Â Â Âon one of the Android-based smartphones, touchscreen input is
> Â Â Â Âignored when the system is suspended, but is handled when idle.

And in N900 touching the screen doesn't bring the device out of idle,
I guess because it's off.

What devices do what on which circumstances on what platform is
completely irrelevant.

> 3. Â Â ÂThe system comes out of idle when a timer expires. ÂIn contrast,
> Â Â Â Âtimers might or might not bring the system out of suspend,
> Â Â Â Âdepending on both hardware capabilities and platform/application
> Â Â Â Âpolicy.

Isn't this solved by range timers?

> 4. Â Â ÂSuspend generally forces devices to go into their low-power
> Â Â Â Âstates immediately. ÂIn contrast, idle generally leaves unused
> Â Â Â Âdevices at full power, relying on timers to shut down these
> Â Â Â Âdevices. ÂIdle thus has shorter average wakeup latencies, but
> Â Â Â Âworse energy efficiency.

Only if you make these assumptions
 1) All the applications use suspend-blockers only when they absolutely must
 2) The user has given the right applications the right access

If not, you'll see much worst energy efficiency. So in theory maybe,
but in practice you can't say that.

-- 
Felipe Contreras
--
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/