From: <josephjang@google.com>
To: gregkh@linuxfoundation.org, rjw@rjwysocki.net, pavel@ucw.cz,
len.brown@intel.com, pmladek@suse.com,
sergey.senozhatsky@gmail.com, rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
jonglin@google.com, woodylin@google.com, markcheng@google.com,
josephjang@google.com
Subject: [PATCH] power: suspend: Add suspend timeout handler
Date: Fri, 16 Oct 2020 11:26:10 +0000 [thread overview]
Message-ID: <00000000000011154c05b1c8083a@google.com> (raw)
Thank you Petr for promptly reply.
> On Fri 2020-10-16 11:51:09, Joseph Jang wrote:
> > From: josephjang <josephjang@google.com>
> >
> > Add suspend timeout handler to prevent device stuck during suspend/
> > resume process. Suspend timeout handler will dump disk sleep task
> > at first round timeout and trigger kernel panic at second round timeout.
> > The default timer for each round is 30 seconds.
> A better solution would be to resume instead of panic().
[Joseph] suspend_timeout() will trigger kernel panic() only when
suspend thread stuck (deadlock/hang) for 2*30 seconds.
At that moment, I don't know how to resume the suspend thread. So I
just could trigger panic to reboot system.
If you have better suggestions, I am willing to study it.
> > Note: Can use following command to simulate suspend hang for testing.
> > adb shell echo 1 > /sys/power/pm_hang
> This looks dangerous. It adds a simple way to panic() the system.
> First, it should get enabled separately. e.g.
> CONFIG_TEST_PM_SLEEP_MONITOR.
> Second, I would add it as a module that might get loaded
> and unloaded.
[Joseph] Agree to enable new compile flag for test module.
I think it is better to create separate patch for the new test module right?
> > diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> > index 8b1bb5ee7e5d..6f2679cfd9d1 100644
> > --- a/kernel/power/suspend.c
> > +++ b/kernel/power/suspend.c
> Using kthread looks like an overkill to me. I wonder how this actually
> works when the kthreads get freezed. It might be enough to implement
> just a timer callback. Start the timer in start_suspend_mon() and
> delete it in stop_suspend_mon(). Or do I miss anything?
> Anyway, the kthread implementation looks a but hairy. If you really
> need to use kthread, I suggest to use kthread_worker API. You would
> need to run an init work to setup the RT scheduling. Then you
> could just call kthread_queue_delayed_work(()
> and kthread_cancel_delayed_work_sync() to start and stop
> the monitor.
[Joseph]
Actually, I had ever think we just need to use
add_timer()/del_timer_sync() for start_suspend_mon()/stop_suspend_mon()
before.
But I am not sure if add_timer() may cause any performance impact in
suspend thread or not.
So I try to create a suspend monitor kthread and just flip the flag in
suspend thread.
> > @@ -114,6 +251,10 @@ static void s2idle_enter(void)
> > s2idle_state = S2IDLE_STATE_NONE;
> > raw_spin_unlock_irq(&s2idle_lock);
> >
> > +#ifdef CONFIG_PM_SLEEP_MONITOR
> > + start_suspend_mon();
> > +#endif
> It is better to solve this by defining start_suspend_mon() as empty
> function when the config option is disabled. For example, see
> how vgacon_text_force() is defined in console.h.
[Joseph] Thank you for good suggestions.
May I know if I could use IS_ENABLED() ?
if (IS_ENABLED(CONFIG_PM_SLEEP_MONITOR))
start_suspend_mon();
> Best Regards,
> Petr
next reply other threads:[~2020-10-16 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 11:26 josephjang [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-10-20 9:01 [PATCH] power: suspend: Add suspend timeout handler josephjang
2020-10-20 9:25 ` Greg KH
2020-10-20 8:15 josephjang
2020-10-20 8:46 ` Greg KH
2020-10-16 13:33 josephjang
2020-10-16 13:22 josephjang
2020-10-16 13:24 ` Rafael J. Wysocki
2020-10-16 13:25 ` Joseph Jang
2020-10-16 11:35 josephjang
2020-10-16 3:51 Joseph Jang
2020-10-16 5:44 ` Greg Kroah-Hartman
[not found] ` <CAPaOXERGzo8uF9gh4aAoicEAi_TtHn1M2Yno5LAWQPcWmq_evQ@mail.gmail.com>
2020-10-16 9:03 ` Greg Kroah-Hartman
2020-10-16 9:30 ` Joseph Jang
2020-10-16 9:01 ` Petr Mladek
2020-10-16 9:54 ` Joseph Jang
2020-10-16 13:03 ` Rafael J. Wysocki
2020-10-16 13:07 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00000000000011154c05b1c8083a@google.com \
--to=josephjang@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonglin@google.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=markcheng@google.com \
--cc=pavel@ucw.cz \
--cc=pmladek@suse.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=woodylin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.