On Mon, 21 Jun 2010, Rafael J. Wysocki wrote: > > After further thought, there's still a race: > > > > A wakeup event arrives. > > > > The kernel increments /sys/power/wakeup_count and starts > > processing the event. > > > > The power-manager process reads /sys/power/wakeup_count. > > You assume that these two steps will occur instantaneously one after the other, > while there may be (and in fact there should be) a delay between them. No, I'm not assuming that. > I would make the power manager wait for certain time after reading > /sys/power/wakeup_count and if no wakeup events are reported to it within > that time, to write to /sys/power/wakeup_count. Why? That's just wasted time -- time during which the system could have been suspended. I can understand the power manager might reason as follows: If this wakeup event hasn't been handed over to a userspace program in the next 5 seconds, I'm going to suspend anyway on the theory that something is wrong. But why do that when you can get exact information? > The length of the time to wait would be system-dependent in general, but I'd > also allow the event consumers to influence it (like when an application knows > it will process things for 10 minutes going forward, so it tells the power > manager to wait for at least 10 minutes before attempting to suspend). It tells the power manager to wait by activating a userspace suspend blocker. While a blocker is active, the power manager doesn't have to poll /sys/power/wakeup_count or anything; it just waits for all the suspend blockers to be deactivated. And there's no guesswork involved; the power manager knows immediately when it's time to try suspending again. > > The power-manager process polls the relevant programs and > > they all say no events are pending. > > > > The power-manager process successfully writes > > /sys/power/wakeup_count. > > > > The power-manager process initiates a suspend. > > > > ... Hours later ... > > > > The system wakes up. > > > > The kernel finishes its internal processing of the event and > > sends a notification to a user program. > > > > The problem here is that the power-manager process can't tell when the > > kernel has finished processing an event. This is true both for events > > that need to propagate to userspace and for events that are handled > > entirely by the kernel. > > > > This is a reflection of the two distinct pieces of information that we > > need to keep track of: > > > > A wakeup event has arrived, so it's no longer safe to suspend. > > > > Wakeup events are no longer pending, so it's once again > > safe to suspend. > > > > The wakeup_count interface tracks the first, but in this scheme nothing > > tracks the second. > > Which I don't think is really necessary, because we'll need to use timeouts > anyway, at least for events that have no user space consumers. You wouldn't need to use timeouts for them either if the kernel had a way to indicate when it was finished processing events. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
