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

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: <AANLkTimqcVYhRxa4JUaiArPHS4_T7I-kbclhVx_jJOt3@mail.gmail.com>
Date:	Thu, 27 May 2010 21:55:26 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>
> This started because the Android people came to a meeting that was put
> together of various folks to try and sort of the big blockage in getting
> Android and Linux kernels back towards merging.
>
> I am interested right now in finding a general solution to the Android
> case and the fact it looks very similar to the VM, hard RT, gamer and
> other related problems although we seem to have diverged from that logic.

I think that the suspend block model can be viewed as a constraints
problem (similar to some of things things you've been sketching out in
these threads), but I think we (Google/Android) view it as more of a
state constraint (don't enter suspend) than a latency constraint.

We think there's a need for these constraints both from the driver
side and userspace side, and that these constraints are not tied to
processes (multiple entities in one process may have different
constraints at different times or multiple processes may be working
together to accomplish some goal under a single constraint -- at least
both cases exist in the Android system as it ships today).

The exact naming of the API is not terribly important to us.  The
first thing we spent a bunch of time discussing last summer when Arve
first looked into sending wakelocks upstream was changing the name
because many objected to "wakelock" for various reasons.

Being able to have userful statistics (which drivers/processes/etc
held which wakelock for how long, how many times, etc) is important to
us.  While we want to do the best we can in the face of poorly written
apps, we also want to educate users and developers about which apps
are contributing to their poor battery life -- so users can decide to
uninstall an app if its usefulness does not justify its impact on
battery life and application developers can be more aware of what the
cost of their app is to endusers.

As an example, http://frotz.net/misc/battery-stats-unplugged.txt
contains a dump from the "battery service" aggregating wakelock usage,
cpu usage, and sensor device usage of processes (#....: sections) on
my phone the other day for a ~3 hour period.  This data is presented
visually to the enduser in a "what's using my battery" feature of the
platform.  "realtime" refers to wall clock time here and "uptime"
refers to not-in-suspend execution time.

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