[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100513200814.GA20254@srcf.ucam.org>
Date: Thu, 13 May 2010 21:08:14 +0100
From: Matthew Garrett <mjg@...hat.com>
To: Tony Lindgren <tony@...mide.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Paul Walmsley <paul@...an.com>,
Arve Hjønnevåg <arve@...roid.com>,
Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
Kevin Hilman <khilman@...prootsystems.com>,
magnus.damm@...il.com, Theodore Ts'o <tytso@....edu>,
mark gross <mgross@...ux.intel.com>,
Arjan van de Ven <arjan@...radead.org>,
Geoff Smith <geoffx.smith@...el.com>,
Brian Swetland <swetland@...gle.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Benoît Cousson <b-cousson@...com>,
linux-omap@...r.kernel.org, Vitaly Wool <vitalywool@...il.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> The system stays running because there's something to do. The system
> won't suspend until all the processors hit the kernel idle loop and
> the next_timer_interrupt_critical() returns nothing.
At which point an application in a busy loop cripples you. I think we
could implement your suggestion more easily by just giving untrusted
applications an effectively infinite amount of timer slack, but it still
doesn't handle the case where an app behaves excrutiatingly badly.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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/
Powered by blists - more mailing lists