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: <20100804062804.GA43413@dspnet.fr>
Date:	Wed, 4 Aug 2010 08:28:04 +0200
From:	Olivier Galibert <galibert@...ox.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	david@...g.hm, "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 <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 Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hjønnevåg wrote:
> 2010/8/3 Olivier Galibert <galibert@...ox.com>:
> > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hjønnevåg wrote:
> >> If you just program the alarm you will wake up see that the monotonic
> >> clock has not advanced and set the alarm another n seconds into the
> >> future. Or are proposing that suspend should be changed to keep the
> >> monotonic clock running?
> >
> > You're supposed to fix the clock after you wake up.  That's part of
> > the cost of going suspend.
> 
> I'm not sure what you are referring to. The generic Linux timekeeping
> code makes sure the monotonic clock stops while the system is
> suspended regardless of what values the (hardware specific)
> clocksource returns.

That just means the android-like suspend should not act in that
specific area the same as the generic suspend to ram.  Which is not
entirely surprising.  In any case, it's not "keep the monotonic clock
running", which would cost power.  It's fix it up afterwards, using
the same means you already do but perhaps at a higher level currently.
People don't want to see the wrong time of the day just because the
phone went to suspend.  Laptop STR is different in perception because
it shuts down things people don't want to see shutdown just by being
idle, namely wifi connectivity.

If your next polling timer is in half an hour and the screen/touchpad
are off, you want to go as low in power as possible until then, and
that's the deepest level of idle you can find that responds to alarms
which may happen to be called suspend.  But from a user point of view,
it's just another idle level.  And from a power management code/policy
decisions point of view, it should be the same.

  OG.

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