linux-kernel - Re: suspend blockers & Android integration

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:	Sun, 6 Jun 2010 12:01:29 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
> >> That is too simple. You also have to prevent A from being frozen while
> >> it is processing the event or the result would be the same as if it
> >> was frozen beforehand.
> >
> > The framework decides when to freeze the app in the first place (as
> > your framework does now when it decides to suspend)
> >
> >     So it knows whether the app is frozen or not.
> >
> >     So it knows damend well whether it processed the event or not.
> >
> 
> Our user-space code is not single-threaded. So just because an app was
> not frozen when you checked does not mean it will remain unfrozen. We
> can use the same user-space wakelock api we have now to prevent
> freezing apps instead of preventing suspend, but we loose any
> advantage we get from freezing just a subset of processes this way.

Errm. That does not matter whether its single threaded or not. And
right, you have to prevent that it gets frozen while you are calling
into it.

But that does not change the fact that you can do finer grained power
control even in the case when suspend is impossible because a
background application has work to finish and does that without
requiring interaction with the frozen part.

That's what I pointed out in the first place and you just argue in
circles why it is impossible to do so.

Let me recapitulate:

   Full on state:	No difference because everything runs
   Full suspend state:	No difference because everything is down

   Screen off, background work active:

   	  Suspend blocker held by the active background work lets
   	  other applications which are unrelated consume CPU cycles
   	  and power.

	  versus

	  Frozen apps restrict the CPU cycles and power consumption to
	  the background work (if there are no interactions with
	  frozen tasks) and therefor save more power than the on/off
	  approach.

	  If your user space stack cannot be distangled that way, then
	  it's a problem of your user space stack and not changing the
	  fact, that a well designedd system allows you to do that.

Any objections ?

Thanks,

	tglx