Hi, On Wednesday, 25 July 2007 14:28, Pavel Machek wrote: > 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? No. If the majority of tasks is frozen and there is only one or two waiting on I/O, to freezer is the only thing that's running and burning the CPU. What for? > Or have you seen some speedups on some particulary perverse workload? OLPC? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
