Rafael J. Wysocki wrote:
> On Thursday 01 October 2009, Pavel Machek wrote:
>>> Freezing isn't exactly the most latency sensitive operation and
>>> there's no reason to burn cpu cycles and power waiting for it to
>>> complete. msleep(10) instead of yield(). This should improve
>>> reliability of emergency hibernation.
>> i don't see how it improves reliability, but its probably ok.
>>
>> Well... for hibernation anyway. I can imagine cgroup users where
>> freeze is so fast that this matters. rjw cc-ed. pavel
>
> Thanks. I'd like to hear from the cgroup freezer people about that.
>
[Adding Matt Helsley to the CC list]
To checkpoint or migrate an application, the cgroup to which it belongs
must be frozen first.
It's a bit down the road, but if one seeks minimum application downtime
during application checkpoint and/or migration, then a (minimum of)
10ms - or multiples of it - may result in a visible/undesired hick-up.
Perhaps avoid it when freezing a cgroup ? or maybe a way for the user
to control this behavior per cgroup ?
Oren.
>>> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
>>> ---
>>> kernel/power/process.c | 13 +++++++++----
>>> 1 files changed, 9 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/kernel/power/process.c b/kernel/power/process.c
>>> index cc2e553..9d26a0a 100644
>>> --- a/kernel/power/process.c
>>> +++ b/kernel/power/process.c
>>> @@ -41,7 +41,7 @@ static int try_to_freeze_tasks(bool sig_only)
>>> do_gettimeofday(&start);
>>>
>>> end_time = jiffies + TIMEOUT;
>>> - do {
>>> + while (true) {
>>> todo = 0;
>>> read_lock(&tasklist_lock);
>>> do_each_thread(g, p) {
>>> @@ -62,10 +62,15 @@ static int try_to_freeze_tasks(bool sig_only)
>>> todo++;
>>> } while_each_thread(g, p);
>>> read_unlock(&tasklist_lock);
>>> - yield(); /* Yield is okay here */
>>> - if (time_after(jiffies, end_time))
>>> + if (!todo || time_after(jiffies, end_time))
>>> break;
>>> - } while (todo);
>>> +
>>> + /*
>>> + * We need to retry. There's no reason to be
>>> + * over-anxious about it and waste power.
>>> + */
>
> The comment above looks like it's only meaningful in the context of the patch.
> After it's been applied the meaning of the comment won't be so obvious, I'm
> afraid.
>
>>> + msleep(10);
>>> + }
>>>
>>> do_gettimeofday(&end);
>>> elapsed_csecs64 = timeval_to_ns(&end) - timeval_to_ns(&start);
>
> Thanks,
> Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
