linux-kernel - Re: [RFC][PATCH 2/2] PM / Sleep: Introduce cooperative suspend/hibernate mode

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: <20111018100620.6334eb1d@notabene.brown>
Date:	Tue, 18 Oct 2011 10:06:20 +1100
From:	NeilBrown <neilb@...e.de>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	mark gross <markgross@...gnar.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 2/2] PM / Sleep: Introduce cooperative
 suspend/hibernate mode

On Mon, 17 Oct 2011 14:43:21 -0700 John Stultz <john.stultz@...aro.org> wrote:

> On Tue, 2011-10-18 at 08:19 +1100, NeilBrown wrote:
> > On Mon, 17 Oct 2011 12:08:49 -0700 John Stultz <john.stultz@...aro.org> wrote:

> > Here I see you probably meant "efficient".  Can that be quantified?  Do you
> > have a target latency for getting into suspend, and measurements that show
> > you regularly missing this target?
> > I am reminded of what Donald Knuth reportedly said about premature
> > optimisation.
> 
> That is a fair point. I think the Android guys have better sense of the
> specifics for suspend latency that they use. But just to get a sense of
> it, on one Android board I've used, the system resumes and suspends for
> each keystroke over the serial line.

Cool!

> 
> >> There is a userland PM daemon. Its responsible for both suspending the
> > > system, *and* handing all wakeup events.
> > > 
> > > Normal wakeup consumers open wakeup devices with a special library which
> > > passes the open request through the PM daemon. The PM daemon opens the
> > > device and provides a pipe fd back to the application, and basically
> > > acts as a middle-man.
> > 
> > There is certainly merit in the idea but I think the pipes just get in the
> > way.
> > 
> > How about having both the PM daemon and the application listening on the same
> > FD.  The app sends the FD to the PM daemon on the same Unix domain socket
> > which is used to request suspend/resume handshaking.
> > 
> > The PM daemon never reads from the FD.  It only passes it to
> > poll/select/whatever.
> > 
> > When poll says  the FD is ready, the daemon initiated the handshake with the
> > app to make sure that it has consumed the event.  If none of the FDs are
> > ready for read and no process is blocking suspend, then the daemon is free to
> > enter suspend.
> 
> So this is starting to sound pretty interesting!
> 
> I think you can drop the handshaking on suspend as well, because you can
> consider the read() on the application side to mark that the event is
> consumed. The application can flag to the pm daemon to inhibit suspend
> after a select, but prior to reading.
> 
> Does that make sense to you?
> 
> This would both avoid the extra context switching to pass the event
> over, and avoids the need to schedule everyone before suspending. 

I'm not sure if you are saying something different to me or not.

In my proposal we do avoid the handshake and context switch unless the fd is
readable when the daemon tries to suspend - and that should be the uncommon
case.
Avoiding some handshake is not possible when the fd is readable.
You could still have an implicit handshake were the daemon knows the app
hasn't handled the event yet because it hasn't read, and the app gets a
stay-awake lock before reading.  However
1/ there is still a handshake and probably a context switch - it is just
   less explicit
2/ the server needs to wait for "fd is not readable" and we don't have an
   interface for that.
   I guess the server could assume that if an fd is readable, then a
   stay-awake request will be made, so it waits for the stay-awake request.
   That feels a little bit fragile, but it might work and it could end up
   being a little more efficient - it would need careful analysis and probably
   some experimentation to be sure.

So yes - maybe it makes sense, but it needs a concrete implementation to
provide proper review.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)