From: Tejun Heo <tj@kernel.org>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: rjw@sisk.pl, pavel@ucw.cz, lenb@kernel.org, ak@linux.intel.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures
Date: Sat, 19 Nov 2011 10:32:40 -0800 [thread overview]
Message-ID: <20111119183240.GA17252@google.com> (raw)
In-Reply-To: <20111117083042.11419.19871.stgit@srivatsabhat.in.ibm.com>
Hello, Srivatsa.
On Thu, Nov 17, 2011 at 02:00:50PM +0530, Srivatsa S. Bhat wrote:
> @@ -380,7 +382,40 @@ static inline void unlock_system_sleep(void) {}
>
> static inline void lock_system_sleep(void)
> {
> - mutex_lock(&pm_mutex);
> + /*
> + * "To sleep, or not to sleep, that is the question!"
> + *
> + * We should not use mutex_lock() here because, in case we fail to
> + * acquire the lock, it would put us to sleep in TASK_UNINTERRUPTIBLE
> + * state, which would lead to task freezing failures. As a
> + * consequence, hibernation would fail (even though it had acquired
> + * the 'pm_mutex' lock).
> + * Using mutex_lock_interruptible() in a loop is not a good idea,
> + * because we could end up treating non-freezing signals badly.
> + * So we use mutex_trylock() in a loop instead.
> + *
> + * Also, we add try_to_freeze() to the loop, to co-operate with the
> + * freezer, to avoid task freezing failures due to busy-looping.
> + *
> + * But then, since it is not guaranteed that we will get frozen
> + * rightaway, we could keep spinning for some time, breaking the
> + * expectation that we go to sleep when we fail to acquire the lock.
> + * So we add an msleep() to the loop, to dampen the spin (but we are
> + * careful enough not to sleep for too long at a stretch, lest the
> + * freezer whine and give up again!).
> + *
> + * Now that we no longer busy-loop, try_to_freeze() becomes all the
> + * more important, due to a subtle reason: if we don't cooperate with
> + * the freezer at this point, we could end up in a situation very
> + * similar to mutex_lock() due to the usage of msleep() (which sleeps
> + * uninterruptibly).
> + *
> + * Phew! What a delicate balance!
> + */
> + while (!mutex_trylock(&pm_mutex)) {
> + try_to_freeze();
> + msleep(10);
> + }
I tried to think about a better way to do it but couldn't, so I
suppose this is what we should go with for now. That said, I think
the comment is a bit too umm.... verbose. What we want here is
freezable but !interruptible mutex_lock() and while I do appreciate
the detailed comment, I think it makes it look a lot more complex than
it actually is. Other than that,
Acked-by: Tejun Heo <tj@kernel.org>
Thank you very much.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-11-19 18:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 8:30 [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures Srivatsa S. Bhat
2011-11-19 18:32 ` Tejun Heo [this message]
2011-11-19 19:35 ` Srivatsa S. Bhat
2011-11-19 21:57 ` Rafael J. Wysocki
2011-11-20 6:03 ` Srivatsa S. Bhat
2011-11-20 10:24 ` Rafael J. Wysocki
2011-11-21 4:36 ` Srivatsa S. Bhat
2011-11-21 7:55 ` Chen Gong
2011-11-21 8:22 ` Srivatsa S. Bhat
2011-11-21 16:40 ` Tejun Heo
2011-11-21 17:04 ` Srivatsa S. Bhat
2011-11-21 17:52 ` Tejun Heo
2011-11-21 18:01 ` Srivatsa S. Bhat
2011-11-21 20:05 ` Rafael J. Wysocki
2011-11-21 18:12 ` [PATCH v4] PM / Memory-hotplug: " Srivatsa S. Bhat
2011-11-21 18:23 ` Tejun Heo
2011-11-21 18:25 ` Srivatsa S. Bhat
2011-11-21 22:41 ` Rafael J. Wysocki
2011-11-21 16:47 ` [PATCH v3] PM/Memory-hotplug: " Tejun Heo
2011-11-21 17:12 ` Srivatsa S. Bhat
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=20111119183240.GA17252@google.com \
--to=tj@kernel.org \
--cc=ak@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=srivatsa.bhat@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).