On Friday 08 May 2009, Nigel Cunningham wrote:> 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. I tried some time ago, but it didn't really work well. The timeout is actually a workaround for the problem that we don't reallyknow if tasks are going to react to our freeze requests and how much time it isgoing to take. The current value of 20 s was chosen after a number ofexperiments showing that in some cases the freezing _was_ going to take somuch time. Of course the question is whether it makes sense to give up earliereven if tasks would eventually freeze, but that's a different issue. Now, I think the Arve's approach is reasonable. If we know in advace thatwe're not going to suspend, it's better to stop the freezing as soon aspossible. Thanks,Rafael_______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
