On 09/17, Rafael J. Wysocki wrote: > > On Fri, Sep 14, 2018 at 6:21 PM Oleg Nesterov <o...@redhat.com> 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. Oleg.