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

From: Nigel Cunningham <ncunningham@crca.org.au>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: u.luckas@road.de, swetland@google.com,
	linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH 3/9] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
Date: Fri, 08 May 2009 11:35:32 +1000	[thread overview]
Message-ID: <1241746532.19600.247.camel@nigel-laptop> (raw)
In-Reply-To: <d6200be20905071822y377d0f10t3adad66d6c49acc1@mail.gmail.com>

Hi.

On Thu, 2009-05-07 at 18:22 -0700, Arve Hjønnevåg wrote:
> 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.

I agree. But a one second timeout is still better than a 20s timeout.

> > 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.

I know. Perhaps we should do something with it, though.

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm