[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100517175820.GA29773@srcf.ucam.org>
Date: Mon, 17 May 2010 18:58:20 +0100
From: Matthew Garrett <mjg@...hat.com>
To: Felipe Balbi <me@...ipebalbi.com>
Cc: James Bottomley <James.Bottomley@...e.de>,
Kevin Hilman <khilman@...prootsystems.com>,
Alan Stern <stern@...land.harvard.edu>,
linux-omap@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
Geoff Smith <geoffx.smith@...el.com>,
Brian Swetland <swetland@...gle.com>,
Kernel development list <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Tejun Heo <tj@...nel.org>,
Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote:
> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example trying to show that the real issue lies on the application
> rather than on kernel.
We know that this problem is mostly uninteresting if your userland is
well written. The sad truth is that it's impossible to trust that your
userland is well written, and broadly impossible to communicate to users
that the reason that their battery life is miserable is because of the
applications and not because of the platform. If you don't believe that
that's a worthwhile use case to deal with then suspend blockers buy you
pretty much nothing. But if you do, then nobody's yet demonstrated
another workable way for this to be handled.
--
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