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

[Felipe Balbi <me@felipebalbi.com>]

On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > For userspace, apps that have polling behavior or are ill-behaved must
> > be found and fixed.  Thanks to tools like powertop, this is a farily
> > easy task.
> 
> That's a bit glib ... powertop can detect power consumption stats on a
> running system ... if you have a polling app preventing your system from
> suspending, powertop isn't necessarily going to find it ... especially
> if the polling interval is of the order of powertop's.  Powertop can
> find the bad tens of wakeups per second, but it only takes one wakup
> every few seconds or so to drain the battery significantly when
> operating on suspend from idle.

you can always increase powertop's interval through command line and
once you went down to 1 wakeup every two seconds, you increase
powertop's interval and try to cut down 10 more ill-behaved apps. And
you keep going until you have e.g. 1 wakeup per minute or whatever your
target is.

> > But really, I don't consider the "ill-behaved app" problem to be a
> > real-world problem.  Both in maemo/meego and Android, if someone
> > writes an app that kills battery life, it will get reported as a bug,
> > or get bad ratings etc.  On these kinds of devices, there is a *stong*
> > developer incentive to not write battery sucking apps.
> 
> I'm not sure this is real world, either.  Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should.  But a phone is a consumer device: the average smart phone
> user just wants to browse the web, get email, go to facebook and play
> with some cool apps.  If one of those cool apps is rogue, they're not
> really going to know which one or how to find it (and firing up powertop
> from the command line isn't something which will occur to them as a
> matter of routine).

Agree with you here.

> One of the nice things that suspend blockers actually does is to give
> the kernel a clear name for the process blocking suspend (and thus
> consuming power).  This allows a nice way to assign power budget to the
> application and present who's using what in a nice visible form, which
> does facilitate the reporting of bad apps, even for the non-developer
> user.

if that's the only thing we want suspend_blockers for, there are other
simpler ways to do it. Just add a kernel debugging option for anyone
doing poll() or keeping a device open() or whatever and you have the
name the of the processes consuming power and preventing system from
going into sleep.

IMO, suspend_blocker is trying to fix application problems in kernel
space by unconditionaly (well sort of) freezing userspace if there are
no suspen_blockers held. So even if application is doing
poll(pfds, ARRAY_SIZE(pfds), 2); that won't be noticed because as long as
the suspend_blocker is released, that poll() will be frozen, no ?

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.

-- 
balbi