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]
Date:	Wed, 4 Aug 2010 17:25:53 -0700 (PDT)
From:	david@...g.hm
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	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 Wed, 4 Aug 2010, Paul E. McKenney wrote:

> On Wed, Aug 04, 2010 at 04:49:22PM -0700, david@...g.hm wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 04:23:43PM -0700, david@...g.hm wrote:
>>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>>
>>>>> We suspend as soon as no wakelocks are held. There is no delay.
>>>>
>>>> So, if I have a bookreader app that is not allowed to get the
>>>> wakelock, and nothing else is running, the system will suspend
>>>> immediatly after I click a button to go to the next page? it will
>>>> not stay awake to give me a chance to read the page at all?
>>>>
>>>> how can any application run without wakelock privilages?
>>>
>>> Isn't a wakelock held as long as the display is lit, so that the
>>> system would continue running as long as the page was visible?
>>
>> what holds this wakelock, and what sort of timeout does it have?
>> (and why could that same timeout be used in other ways instead)
>
> I defer to the Android guys on what exactly holds the display's
> wakelock.  The timeout is the display-blank timeout.
>
>> how many apps really need to keep running after the screen blanks?
>> there are a few (audio output apps, including music player and
>> Navigation directions), but I don't have see a problem with them
>> being marked as the 'trusted' apps to pay attention instead.
>
> Downloading is another.

this is definantly an interesting case, do you want an active network 
connection to keep the machine awake? if so do you want it for all network 
connections, or only for some...

> The music player is an interesting example.  It would be idle most
> of the time, given that audio output doesn't consume very much CPU.
> So you would not want to suspend the system just because there were
> no runnable processes.  In contrast, allowing the music player to
> hold a wake lock lets the system know that it would not be appropriate
> to suspend.
>
> Or am I misunderstanding what you are proposing?

the system would need to be idle for 'long enough' (configurable) before 
deciding to suspend, so as long as 'long enough' is longer than the music 
player is idle this would not be a problem.

>> if the backlight being on holds the wakelock, it would seem that
>> almost every other use of the wakelock could (and probably should)
>> be replaced by something that tickles the display to stay on longer.
>
> The problem with this approach is that the display consumes quite a
> bit of power, so you don't want to leave it on unnecessarily.  So if
> the system is doing something (for example, playing music) that does
> not require the display, you really want the display to be off.

what percentage (and types) of apps are really useful with the display 
off. I think that there are relativly few apps that you really want to 
keep running if the display is off.

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/

Powered by blists - more mailing lists