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: <alpine.DEB.2.00.1008051312220.23543@asgard.lang.hm>
Date:	Thu, 5 Aug 2010 13:26:18 -0700 (PDT)
From:	david@...g.hm
To:	kevin granade <kevin.granade@...il.com>
cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, 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 Thu, 5 Aug 2010, kevin granade wrote:

> On Thu, Aug 5, 2010 at 10:46 AM,  <david@...g.hm> wrote:
>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, david@...g.hm wrote:
>>>>
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, david@...g.hm wrote:
>>>>>>
>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>
>>> [ . . . ]
>>>
>> however, in the case of Android I think the timeouts have to end up being
>> _much_ longer. Otherwise you have the problem of loading an untrusted book
>> reader app on the device and the device suspends while you are reading the
>> page.
>>
>> currently Android works around this by having a wakelock held whenever the
>> display is on. This seems backwards to me, the display should be on because
>> the system is not suspended, not the system is prevented from suspending
>> because the display is on.
>>
>> Rather than having the display be on causing a wavelock to be held (with the
>> code that is controls the display having a timeout for how long it leaves
>> the display on), I would invert this and have the timeout be based on system
>> activity, and when it decides the system is not active, turn off the display
>> (along with other things as it suspends)
>
> IIRC, this was a major point of their (Android's) power management
> policy.  User input of any kind would reset the "display active"
> timeout, which is the primary thing keeping random untrusted
> user-facing programs from being suspended while in use.  They seemed
> to consider this to be a special case in their policy, but from the
> kernel's point of view it is just another suspend blocker being held.
>
> I'm not sure this is the best use case to look at though, because
> since it is user-facing, the timeout durations are on a different
> scale than the ones they are really worried about.  I think another
> category of use case that they are worried about is:
>
> (in suspend) -> wakeup due to network -> process network activity -> suspend
>
> or an example that has been mentioned previously:
>
> (in suspend) -> wakeup due to alarm for audio processing -> process
> batch of audio -> suspend

when you suspend the audio will shut off, so it's sleep ->wake -> sleep, 
not suspend

> In both of these cases, the display may never power on (phone might
> beep to indicate txt message or email, audio just keeps playing), so
> the magnitude of the "timeout" for suspending again should be very
> small.  Specifically, they don't want there to be a timeout at all, so
> as little time as possible time is spent out of suspend in addition to
> the time required to handle the event that caused wakeup.

it really depnds on the frequency of the wakeups.

if you get a network packet once every 5 min and need to wake to process 
it, staying awake for 20 seconds after finishing procesing is FAR more 
significant than if you get a network packet once every hour. It's not 
just the factor of 20 that simple math would indicate because the time in 
suspend eats power as well.

I don't know real numbers, so these are made up for this example

if suspend (with the cell live to receive packets) is 10ma average current 
and full power is 500ma average current

packets every 5 min with .1 sec wake time will eat ~13maH per hour

packets every 5 min with 10 second wake time will eat ~37maH per hour

packets every hour with .1 sec wake time will eat ~10maH per hour

packets every hour with 10 sec wake time will eat ~11maH per hour

so if you have frequent wakeups, staying awake 100 times as long will cut 
your battery life to 1/3 what it was before.

if your wakeups are rare, it's about a 10% hit to stay awake 100 times as 
long.

there is a lot of room for tuning the timeouts here.

David Lang
--
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/