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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTim474Yp=MP3EX9pabc9XO8Q-McCns207SLPYuUb@mail.gmail.com>
Date:	Tue, 3 Aug 2010 15:23:00 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	paulmck@...ux.vnet.ibm.com
Cc:	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

2010/8/3 Paul E. McKenney <paulmck@...ux.vnet.ibm.com>:
> On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hjønnevåg wrote:
>> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
>> <paulmck@...ux.vnet.ibm.com> wrote:
...
>> > o       Statistics of the power-control actions taken by power-aware
>> >        applications must be provided, and must be keyed off of program
>> >        name.
>>
>> We don't key the stats off the program name, but having useful
>> statistics is critical too us. The current code in linux-next does not
>> appear to allow this (I'm referring to pm_stay_awake here, etc not
>> pm-qos.)
>
> OK, maybe I was confused earlier.  So you do not track statistics via
> the device being open throughout the application's lifetime?
>

The suspend blocker patchset does track statistics while the device is
open, but it it not keyed of the program name. The name is passed from
user-space and a single process can have the device open several
times. The wakelock interface that we currently use just creates a new
object every time it sees a new name and never frees it.

...
>> > o       If no power-aware or power-optimized application are indicating
>> >        a need for the system to remain operating, the system is permitted
>> >        (even encouraged!) to suspend all execution, even if power-naive
>> >        applications are runnable.  (This requirement did appear to be
>> >        somewhat controversial.)
>>
>> I would say it should suspend even if power aware applications are
>> runnable. Most applications do not exclusively perform critical work.
>
> The point being that a power-aware application does not block suspend
> -unless- it holds a suspend blocker, correct?

Yes.

>
> Or am I missing some other subtlety?

No.

...
>> > o       Any initialization of the API that controls the system power
>> >        state must be unconditional, so as to be free from failure.
>> >        (I don't currently understand how this relates, probably due to
>> >        my current insufficient understanding of the proposed patch set.)
>>
>> Unconditional initialization makes it easier to add suspend blockers
>> to existing kernel code since you don't have to add new failure exit
>> paths. It is not a strong requirement.
>
> Ah, that makes more sense!  I moved this to a new "NICE-TO-HAVES"
> section.  I also changed the last parenthesized sentence to read
> "Such unconditional initialization reduces the intrusiveness of the
> the Android patchset."  Does that work?
>

Sure.



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