Hi! > Use the observation that try_to_freeze() need not loop while waiting for the > freezing tasks to enter the refrigerator and make it use a wait queue. > > The idea is that after sending freeze requests to the tasks regarded as > freezable try_to_freeze() can go to sleep and wait until at least one task > enters the refrigerator. The first task that does it wakes up try_to_freeze() > and the procedure is repeated. If the refrigerator is not entered by any tasks > before TIMEOUT expires, try_to_freeze() increases the counter of expired > timeouts and sends freeze requests to the remaining tasks. If the number of > expired timeouts becomes greater than MAX_WAITS, the freezing of tasks fails > (the counter of expired timeouts is reset whenever a task enters the > refrigerator). > > This way, try_to_freeze() doesn't occupy the CPU unnecessarily when some > freezing tasks are waiting for I/O to complete and we have more fine grained > control over the freezing procedure. > > Signed-off-by: Rafael J. Wysocki <rjw@xxxxxxx> > Acked-by: Nigel Cunningham <nigel@xxxxxxxxxxxxxxxxxx> > --- > kernel/power/process.c | 70 +++++++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 59 insertions(+), 11 deletions(-) But is this really neccessary? It is not like the freezing phase of suspend is particulary time critical, and this only makes it more complex. We do not poll the task _that_ often that this matters, right? Or have you seen some speedups on some particulary perverse workload? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
