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)? 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? > >> 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? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
