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

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: <20100517174647.GA11512@gandalf>
Date:	Mon, 17 May 2010 20:47:31 +0300
From:	Felipe Balbi <me@...ipebalbi.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	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>,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

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