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]

Message-ID: <Pine.LNX.4.44L0.1005271853430.29316-100000@netrider.rowland.org>
Date:	Thu, 27 May 2010 19:02:28 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	<felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

Matthew:

Remind me why the idle/QOS power management approach won't work here.

If the difficulty is untrusted apps preventing the system from being
idle, why not assign them to QoS(NONE) as Thomas suggested?

If the difficulty is that some untrusted apps need to receive wakeup 
events, why not just decree that this is not allowed?  It seems 
reasonable that if you can't trust a program then you shouldn't allow 
it to wake up the system.

If the difficulty is that some trusted apps need to do CPU-burning
things like drawing bouncing cows in the background, why not break
these apps into two processes or threads?  One can be trusted and
receive all the wakeup events, and the other can be untrusted and draw
all the cows it likes.  We're only talking about trusted apps, most of
which would be controlled by Google, so the conversion shouldn't be too
hard.

If the difficulty is that ACPI-based systems can't use idle/QOS PM
effectively...  well, so be it.  We don't have to solve every problem
in the world right away, and just now we're mainly concerned about
helping the Android people.

Alan Stern

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