Re: [RFC][PATCH -mm 2/2] Freezer: Use wait queue instead of busy looping

["Rafael J. Wysocki" <rjw@sisk.pl>]

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@sisk.pl>
> > Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
> > ---
> >  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