Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Thu Aug 05 2010 - 10:35:35 EST

On Thu, 5 Aug 2010, Matthew Garrett wrote:

On Wed, Aug 04, 2010 at 03:20:04PM -0700, david@xxxxxxx wrote:

similar to the current implementation, the arrival of a packet could be
counted as activity that keeps the system awake for a bit (your timeout)

How? You're either polling in order to know whether there's network
activity, or you're having every network packet wake up the policy
daemon, or you've got something that looks like the kernel side of

infrequent polling (on the order of seconds or 10s of seconds) is not a very significant impact on your power

Cell networks typically have no background traffic, for obvious reasons.

but don't most new smartphones also connect up to wifi networks? those
are FAR from quiet.

Wifi radio typically dwarfs your other power consumption anyway. The
typical situation is one where you're not attached to a wifi network.

on some devices (my kindle for example) the cell network dwarfs my other power consumption today.

I'm not suggesting running all events through some central server (unless
you count the kernel as that server), I'm saying that the decision that
the system is idle and therefor can be stopped should be able to take
this infomation into account, and if there's a race here, it should be a
race that exists everywhere else, so there should be a general solution,
not something specific to one use-case. (and definantly not something
that requires all software to be modified and trusted to implement)

You're right. It's a race that exists everywhere else, and it's inherent
unless you have some handshaking between userspace and the kernel when
entering suspend. Which is what wakelocks provide. Nobody has proposed a
solution that works without modifying existing code.

I think the issue is confusion between the different purposes of the wakelock.

as you say, I don't think anyone is opposed to the kernel being modified to eliminate this race. The disagreement is far more about the interface to userspace and userspace use of wakelocks.

the kernel implementation of this doesn't have to set a single flag, and it doesn't have to notify userspace directly. The kernel already produces many stats today and it may be appropriate for the kernel to produce some more.

for example, if you want to abort the suspend because there is network activity, you can check the packet count of your network interface, decide to go to sleep, setup the network interface to raise a 'wake me up' interrupt (because you have decided in a userspace policy that you want this), and then check to see if the packet count has changed. If it has, abort the suspend, if not continue the suspend and once you are suspended if the 'wake me up' interrupt is set you will wake back up.

there are probably cleaner/better ways of doing this than the simple logic that I'm listing, but why wouldn't the simple logic provide the correct result?

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at