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]

Date:	Mon, 2 Aug 2010 21:44:44 -0700 (PDT)
From:	david@...g.hm
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	"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 Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:

> On Mon, Aug 2, 2010 at 5:08 PM,  <david@...g.hm> wrote:
>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>
>>
>> you are close, but I think what I'm proposing is actually simpler (assuming
>> that the scheduler can be configured to generate the appropriate stats)
>>
>> my thought was not to move applications between cgroups as they
>> aquire/release the suspend-block lock, bur rather to say that any
>> application that you would trust to get the suspend-block lock should be in
>> cgroup A while all other applications are in cgroup B
>>
>> when you are deciding if the system shoudl go to sleep because it is idle,
>> ignore the activity of all applications in cgroup B
>>
>> if cgroup A applications are busy, the system is not idle and should not
>> suspend.
>>
>
> Triggering suspend from idle has been suggested before. However, idle
> is not a signal that it is safe to suspend since timers stop in
> suspend (or the code could temporarily be waiting on a non-wakeup
> interrupt). If you add suspend blockers or wakelocks to prevent
> suspend while events you care about are pending, then it does not make
> a lot of sense to prevent suspend just because the cpu is not idle.

isn't this a matter of making the suspend decision look at what timers 
have been set to expire in the near future and/or tweaking how long the 
system needs to be idle before going to sleep?

to properly do a good job at suspending hyperagressivly you need to look 
at when you need to wake back up (after all, if you are only going to 
sleep for 1 second, it makes no sense to try and enter a sleep state that 
takes .5 seconds to get into and .6 seconds to get out of, you need to 
pick a lighter power saving mode)

if you really want to have the application be able to say 'I am ready for 
you to go to sleep NOW and I don't want any chance of waking back up until 
the system is ready for me to do so' it may be possible to have a special 
dev file that when a program attempts to read from it the program is 
considered to have been idle forever (expiring any 'delay since last 
activity' timers that are running for that process) and when the device 
wakes back up (or after a little bit of time if the device decides not to 
go back to sleep), allow the return from the blocking call to allow the 
app to continue running.

but I am not sure that something like that is needed. I think just 
checking for timers that are due to expire 'soon' and tweaking how long 
the system must be 'idle' before it decides to go to sleep should be good 
enough.

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/