Re: [linux-pm] suspend blockers & Android integration

[Arve Hjønnevåg]

2010/6/10 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
>
>> >> For that to work the wakeup events would have to be reported to the
>> >> power manager in a reliable way in the first place. Passing the file
>> >> descriptor that the app uses to the power manager does not work for
>> >> this, since the app could read the event while the power manager was
>> >> not in the poll call and the power manager would never see it.
>> >
>> > If the app activates a suspend blocker before reading the event, this
>> > doesn't matter.  If the app doesn't activate a suspend blocker then it
>> > risks being suspended after it has read the event but before it has
>> > handled the event.  This is equally true with wakelocks.
>> >
>>
>> It is not the same. Using a wakelock with a timeout only has a problem
>> if the app did not get a change to run and block suspend before the
>> timeout expires. With the timeout values we use there is only a
>> problem if the system is already unresponsive. If the driver does not
>> block suspend but instead a power manager calls select or poll on a
>> file descriptor while the app does a blocking read, the power manager
>> can easily miss the event and suspend before the app blocks suspend.
>
> You've lost me.  If the power manager is sitting inside a select/poll,
> how can it miss the event (given that the event will make data
> available to be read on one of the descriptors being polled)?
>

It cannot sit inside of select/poll all the time.

> Or put it another way: With wakelocks, if the app doesn't use a suspend
> blocker then once it reads the event data and the timed wakelock is
> deactivated, there is nothing to prevent the system from immediately
> going into opportunistic suspend.  My scheme can fail in the same way.
> Is that what you meant?
>

No, if an app reads from a file descriptor and block suspend when the
read call returns, then suspend is blocked while processing the data.
If the driver uses a wakelock with a timeout this will fail if the
thread does not get to the suspend block call before the timeout
expires, but unrelated events that don't prevent the app from running
will not cause any problems. In your scheme the user-space power
manager may miss events on this file descriptor since select/poll will
not see an event if the app read that event right before the power
manager called select/poll.

>> >> The suspend blocker approach is more generally useful since it
>> >> supports hardware where suspend is needed. Why this argument is being
>> >> ignored is very puzzling.
>> >
>> > Probably because people doesn't envision system suspend being used for
>> > dynamic power management on that kind of hardware.
>> >
>>
>> I'm not sure what you mean by dynamic power management here (frequency
>> of suspends?), but auto suspend is already in use on x86 desktops and
>> laptops. Suspend blockers can fix the race with some wakeup events
>> there.
>
> You should stress this point more strongly when conversing with others.
> I doubt it will be enough to change anybody's mind, but it can't hurt.
> Indeed, if you propose suspend blockers as a way to fix a lost-wakeup
> bug in existing distributions, rather than as something needed to
> support Android, people might view it more favorably.
>
>
> There's one question that I don't remember ever seeing answered.  To
> which kernel drivers do you intend to add suspend blockers?
>

All drivers that generate wakeup events need to either use suspend
blockers directly or call into something else that does. For instance,
with the patch to block suspend while input events are queued to
user-space, an input driver that fully handles its events in its
interrupt handler does not need any additional suspend blockers, but
if the driver needs a work function or a timer to run before it
reports the event it needs to block suspend until it has reported the
event.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/