linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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:	Sat, 29 May 2010 10:10:18 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	tytso@....edu, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote:
> On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Fri, 2010-05-28 at 00:31 -0400, tytso@....edu wrote:
> >> Keep in mind, though, that a solution which is acceptable for Android
> >> has to include making sure that crappy applications don't cause the
> >> battery to get drained.  There seem to be some people who seem
> >> adamently against this requirement.
> >
> > Again, Alan, Thomas and myself don't argue against that, what we do
> > however argue against is suspend running apps as a form of power
> > management.
> >
> 
> You seem to argue that android is not allowed to use suspend because
> the hardware we have shipped on can enter the same power state from
> idle. From my point of view, since we need to support suspend on some
> hardware we should be allowed to leverage this solution on the better
> hardware platforms as well if it improves our battery life.

Correct, I strongly oppose using suspend. Not running runnable tasks is
not a sane solution.

If current hardware can't cope, too friggin bad, get better hardware.

But the truth is, all your OMAP phones really can deal with it.

> I have not seen any suggestions for how to deal with all our
> interprocess dependencies when pausing a subset of processes. Without
> a solution to that we can only pause a subset of the processes we want
> to pause.

Do not 'pause' processes and you don't have the problem, make them stop
on their own accord or kill them if they dont listen.. who cares about
ill-behaved apps anyway?

But really, if you want a more detailed answer, you need to provide more
detail on these problems.

If you want to allow an untrusted app to provide a dependency for a
trusted app, you've lost and I don't care.

Trusted apps should be well behaved, otherwise there really is no point.

> These solutions do not allow us to use suspend. They may get us closer
> to the power consumption we get from suspend on the good hardware or
> even surpass it, but we still need suspend on some hardware, and we
> would get event better results by using these solutions in addition to
> suspend compared to using them instead of suspend.

Not using suspend is exactly the point. As Alan has argued, propagating
suspend blockers up into all regions of userspace will take much longer
than fixing the hardware.

You got to realize this is about Linux as a whole, I really don't care
one whit about the specific Android case. We want a solution that is
generic enough to solve the power consumption problem and makes sense on
future hardware.

The only abstraction that really makes sense in that view is idle
states.

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