linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikr6CW5AP9=ZVvyMUar39tPX2QcJbY3a4EFDEkN@mail.gmail.com>
Date:	Tue, 3 Aug 2010 22:22:55 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	paulmck@...ux.vnet.ibm.com, david@...g.hm,
	"Ted Ts'o" <tytso@....edu>, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <arjan@...radead.org> wrote:
> On Tue, 3 Aug 2010 17:10:15 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
>>
>> OK, I'll bite...
>>
>> >From an Android perspective, the differences are as follows:
>>
>> 1.    Deep idle states are entered only if there are no runnable
>> tasks. In contrast, opportunistic suspend can happen even when there
>>       are tasks that are ready, willing, and able to run.
>
> for "system suspend", this is an absolutely valid statement.
> for "use suspend as idle state", it's not so clearly valid.
> (but this is sort of a separate problem, basically the "when do we
> freeze the tasks that we don't like for power reasons" problem,
> which in first order is independent on what kind of idle power state
> you pick, and discussed extensively elsewhere in this thread)
>
>>
>> 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 a deep
>>       idle state.  For example, I believe that it was stated that
>> one of the Android-based smartphones ignores touchscreen input while
>>       suspended, but pays attention to it while in deep idle states.
>
> I would argue that this is both a hardware specific issue, but also a
> policy issue. From the user point of view, screen off with idle and
> screen off with suspend aren't all that different (if my phone would
> decide to idle rather than suspend because some app blocks suspend... I
> wouldn't expect a difference in behavior when I touch the screen).
> "Screen off -> don't honor touch after a bit" is almost an independent,
> but very real, policy problem (and a forced one in suspend, I'll grant
> you that). I could even argue that the policy decision "we don't care
> about the touch screen input" is a pre-condition for entering suspend
> (or in android speak, caring for touch screen input/having the touch
> screen path active would be a suspend blocker)
>
>>
>> 3.    The system comes out of a deep idle state when a timer
>>       expires.  In contrast, timers cannot expire while the
>>       system is suspended.  (This one is debatable: some people
>>       argue that timers are subject to jitter, and the suspend
>>       case for timers is the same as that for deep idle states,
>>       but with unbounded timer jitter.  Others disagree.  The
>>       resulting discussions have produced much heat, but little
>>       light.  Such is life.)
>
> I'll debate it even harder in that it's platform specific whether
> timers can get the system out of suspend or not. Clearly on the Android
> platform in question that's not the case, but for some of the Intel
> phone silicon for example, timers CAN be wake sources to get you out of
> suspend just fine. It just depend on which exact hw you talk about.
> Generally, even if the fast timers aren't wake up sources, there'll be
> some sort of alarm thing that you can pre-wake.. but yes you are right
> in saying that's rather lame.
> Either way, it's not a general property of suspend, but a property of
> suspend on the specific platform in question.
>

I disagree. On the msm platform the low level timer that brings us out
of the low power state is the same for idle and suspend. The
difference is where which kernel api the request comes from. In idle,
the next event on the clockevents device is usually the first event.
In suspend the generic kernel timekeeping code cancels this event and
the rtc wakeup event remains.

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