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: <AANLkTinFT5jq4nUhUpzS5S4TVDQGj0S7RtRgxNhsz2UF@mail.gmail.com>
Date:	Tue, 3 Aug 2010 15:47:38 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	david@...g.hm
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

2010/8/2  <david@...g.hm>:
> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/2  <david@...g.hm>:
>>>
>>> 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?
>>>
>>
>> You are describing low power idle modes, not suspend. Most timers stop
>> in suspend, so a timer set 10 seconds from now when entering suspend
>> will go off 10 seconds after resume so it should have no impact on how
>> long you decide to stay in suspend.
>
> so what is the fundamental difference between deciding to go into low-power
> idle modes to wake up back up on a given point in the future and deciding
> that you are going to be idle for so long that you may as well suspend until
> there is user input?
>

Low power idle modes are supposed to be transparent. Suspend stops the
monotonic clock, ignores ready threads and switches over to a separate
set of wakeup events/interrupts. We don't suspend until there is user
input, we suspend until there is a wakeup event (user-input, incoming
network data/phone-calls, alarms etc..).

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