[lkml]   [2018]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] kernel/hung_task.c: disable on suspend
On 09/17, Rafael J. Wysocki wrote:
> On Fri, Sep 14, 2018 at 6:21 PM Oleg Nesterov <> wrote:
> >
> > > > Since you are adding the notifier anyway, what about designing it to make
> > > > the thread wait on _PREPARE until the notifier kicks it again on exit
> > > > fron suspend/hibernation?
> >
> > Well. I agree that freezable kthreads are not nice, but it seems you are
> > going to add another questionable interface ;)
> Why would it be questionable?
> The watchdog needs to be disarmed somehow before tasks are frozen and
> re-armed after they have been thawed or it may report false-positives
> on the way out. PM notifiers can be used for that.

Or watchdog() can simply use set_freezable/freezing interface we already
have, without additional complications.

Yes, this is not "before tasks are frozen", but probably should work?

OK, I won't argue.

> > Where does the caller of pm_suspend() sleep in D state? Why it sleeps more
> > than 120 seconds?
> It need not be sleeping for over 2 minutes, but if suspend-to-idle
> advances the clock sufficiently, the watchdog will regard that as the
> task sleep time.

As I already said, I don't understand this magic, so you can ignore me.

But again, it would be nice to explain this in the changelog, I mean, how
exactly (and why) jiffies can grow for over 2 minutes in this case.

> > And. given that it takes system_transition_mutex anyway, can't it use
> > lock_system_sleep() which marks the caller as PF_FREEZER_SKIP (checked
> > in check_hung_task()) ?
> Well, it could, but that would be somewhat confusing and slightly
> abusing the flag IMO.

OK, I won't insist.


 \ /
  Last update: 2018-09-17 18:56    [W:0.144 / U:1.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site