On Sat, 21 Feb 2009, Rafael J. Wysocki wrote: > > I think everything that uses a "trigger" logic from user space is not > > a good idea. This will necessary introduce a race between the decision > > and the execution during which circumstances can change. > > Well, in this particulare case if the circumstances change in the meantime, > the kernel will just refuse to suspend. Also, even if the kernel starts > automatic suspend, it _still_ is possible that the conditions change in the > meantime (for example, one of the tasks may enter a state in which it wouldn't > like to the suspend to happen just after the operation is started and before > it's frozen). > > > So it seems to me that an allow/disallow system from user space > > would be better. > > I don't really see the benefit, but I can easily see drawbacks (the handling > of graphics that requires user space quirks, for instance). This discussion is circling around an important point: How should auto-sleep be initiated? If userspace holds any wakelocks then the system mustn't auto-sleep. So auto-sleep can be initiated when the last userspace wakelock is released. That requires calling into the kernel anyway, so it isn't a problem. But what about kernel wakelocks? Again, the simplest approach is to initiate an auto-sleep when the last one is released. But now this depends on how the implementation works. In Rafael's scheme there isn't really such a thing as a kernel wakelock. Instead there are driver methods, so the only way to find out whether auto-sleep is allowed is to poll every driver. This is not good for systems that want to auto-sleep as soon as possible. A variant on the scheme would use a new field in the dev_pm_info structure. I don't know if this is better or worse the a new method; it seems likely that the new method would have to work by checking the value of some field anyway. In any case, it shares the drawback that polling is required. If kernel wakelocks were implemented more like refcounts, then releasing the last one could immediately initiate an auto-sleep. The problem with refcounts is that you can't tell (for accounting or debugging purposes) who owns the outstanding references. However we ought to be able to come up with something intermediate between a full-blown wakelock and a simple refcount that would satisfy everybody. For example, we could use _both_ a new field in dev_pm_info and a refcount. Or even a per-cpu refcount, to avoid cache-line contention since drivers are likely to acquire and release these things quite often. What about the overhead of having a permanent kernel thread that does nothing but handle auto-sleeps? This might well be an acceptable tradeoff for many people. Besides, you need something like it if a driver wants to release the last wakelock while in interrupt context. Unless you fall back on polling -- and then you need a thread to do the polling. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
