Messages in this thread | | | From | Oliver Neukum <> | Subject | Re: [RFD] Automatic suspend | Date | Sat, 21 Feb 2009 00:12:01 +0100 |
| |
Am Freitag 20 Februar 2009 16:56:59 schrieb Rafael J. Wysocki:
> OK, so what about the following approach: > > * Keep the decision making logic (power manager etc.) in user space. > Reasons: - It may be arbitrarily complicated
Therefore something functionally equivalent to wakelocks is needed.
> - It may include such things as s2ram quirks or hal quirks needed for > some graphics adapters
If you can't do that I'd say the situation is hopeless. You need full support for all devices including graphics cards.
> * Have a per-process (per-task or per-thread group, but the former would be > easier IMO) "I_do_not_want_automatic_suspend_to_occur" flag.
I think you got the default logic inverted.
> * Add a new callback, say ->acknowledge(), to the set of each driver's PM > operations, that will be called to check if the driver has anything > against automatic suspend (true - suspend can happen right now, false - > suspend can't happen). > > * Introduce /sys/power/sleep that will work like /sys/power/state, but: > - First, it will call ->acknowledge() for each driver (via bus types) to > check if any of them wants to postpone the suspend (this will prevent > tasks from being frozen unnecessarily if it is known in advance that the > suspend should not happen at the moment).
Ideally most devices should be already suspended, so I am not sure a new callback is really needed. In any cases it is an optimization only.
> - Next, it will check the "I_do_not_want_automatic_suspend_to_occur" flag > of each process and the suspend will be aborted if it is true for any > of them (quite frankly, I think that should be integrated with the freezer, > in particular the tasks that have TIF_FREEZE set shouldn't be able to set > this flag and it should be checked in the freezer loop for every task with > TIF_FREEZE unset).
Why in this order?
> - Next, it will proceed with suspending just like /sys/power/state does > (the drivers that missed the opportunity to abort the suspend by returning > 'false' from ->acknowledge() can still abort the suspend by failing their > ->suspend() routines). > > Then, the decision making logic will be able to use /sys/power/sleep > whenever it wishes to and the kernel will be able to refuse to suspend if > it's not desirable at the moment.
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.
So it seems to me that an allow/disallow system from user space would be better.
Regards Oliver
| |