Re: [PATCH 3/9] PM: suspend_block: Abort task freezing if a suspend_blocker is active.

Arve Hjønnevåg
2009-05-08T01:22:40Z

2009/5/7 Nigel Cunningham <ncunningham@crca.org.au>:
> Hi.
>
> On Thu, 2009-05-07 at 16:49 -0700, Arve Hjønnevåg wrote:
>> On Thu, May 7, 2009 at 3:41 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> > If the code runs for 20 seconds, it is a bug to be fixed.
>>
>> The code gives up after 20 seconds, it does not normally run for 20
>> seconds. It is arguably a bug that it gives up after 20 seconds since
>> the time required to freeze all the threads grows with the number of
>> threads that are running. It could still be making progress after 20
>> seconds. Since the time required to freeze all tasks is the number of
>> tasks times the time it takes to interrupt each task there is no way
>> to ensure that the time required is insignificant. If we do not abort
>> task freezing when there is a wakeup event, then the worst case wakeup
>> latency is guarantied to be worse than the worst case latency for any
>> other uninterruptible kernel call.
>
> I agree with Pavel here. If freezing takes 20 seconds, something is
> wrong. (Remember that most tasks will not be running, and will therefore
> respond to the pseudo-signal and freeze immediately).
>
> In fact, I'd go further. In the thousands of times I've run the freezer
> over the years, it has never taken more than 1 second - let alone 20 -

One second is to long.

> when freezing has been successful. A delay of 20 seconds was more
> relevant when the value included the time for syncing data to disk.

This patch does nothing with the 20 second timeout.

--
Arve Hjønnevåg