linux-kernel - Re: [PATCH 1/8] PM: Opportunistic suspend support.

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: <1274894042.4467.727.camel@mulgrave.site>
Date:	Wed, 26 May 2010 12:14:02 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Arve Hjønnevåg <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-doc@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>,
	Greg KH <gregkh@...e.de>, tytso@....edu
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Wed, 2010-05-26 at 19:00 +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 11:54 -0500, James Bottomley wrote:
> > Given that I'm in the latter category, I think suspend blockers is a
> > reasonable solution to an existing problem.  I like Alan's idea of
> > restricting the API into a single user space program so we contain the
> > API contamination ... but realistically that's mostly the current
> > suspend blockers anyway. 
> 
> There's a _large_ difference between resource limits and these wonky
> suspend blockers.

Well, you have policy and then you have implementation ... suspend
blockers just looks like an implementation to me.  It seems to be
reasonably well suited in that regard ... after all, we kill processes
that exhaust memory for instance or cut off write privileges to those
that go over quota.  Preventing power hungry processes from consuming
power by not allowing them to run until there's a wakeup event is fairly
gentle by those standards.

> The main and most important one being that suspend is a global property
> and can/will hurt sensible tasks. It puts the whole task model upside
> down.

OK, so I believe you have an android phone ... it already implements
this model ... specifically what are the problems on that platform this
causes?

James


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