Hi. On Thu, 2009-05-07 at 18:22 -0700, Arve Hjønnevåg wrote:> 2009/5/7 Nigel Cunningham <ncunningham@xxxxxxxxxxx>:> > 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@xxxxxx> 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 listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
