All of lore.kernel.org
 help / color / mirror / Atom feed
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>

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2011-11-19 18:32 UTC|newest]

Thread overview: 40+ 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-17  8:30 ` Srivatsa S. Bhat
2011-11-19 18:32 ` Tejun Heo [this message]
2011-11-19 18:32   ` Tejun Heo
2011-11-19 19:35   ` Srivatsa S. Bhat
2011-11-19 19:35     ` Srivatsa S. Bhat
2011-11-19 21:57 ` Rafael J. Wysocki
2011-11-19 21:57   ` Rafael J. Wysocki
2011-11-20  6:03   ` Srivatsa S. Bhat
2011-11-20  6:03     ` Srivatsa S. Bhat
2011-11-20 10:24     ` Rafael J. Wysocki
2011-11-20 10:24       ` Rafael J. Wysocki
2011-11-21  4:36       ` Srivatsa S. Bhat
2011-11-21  4:36         ` Srivatsa S. Bhat
2011-11-21  7:55         ` Chen Gong
2011-11-21  7:55           ` Chen Gong
2011-11-21  8:22           ` Srivatsa S. Bhat
2011-11-21  8:22             ` Srivatsa S. Bhat
2011-11-21 16:40         ` Tejun Heo
2011-11-21 16:40           ` Tejun Heo
2011-11-21 17:04           ` Srivatsa S. Bhat
2011-11-21 17:04             ` Srivatsa S. Bhat
2011-11-21 17:52             ` Tejun Heo
2011-11-21 17:52               ` Tejun Heo
2011-11-21 18:01               ` Srivatsa S. Bhat
2011-11-21 18:01                 ` Srivatsa S. Bhat
2011-11-21 20:05                 ` Rafael J. Wysocki
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:12               ` Srivatsa S. Bhat
2011-11-21 18:23               ` Tejun Heo
2011-11-21 18:23                 ` Tejun Heo
2011-11-21 18:25                 ` Srivatsa S. Bhat
2011-11-21 18:25                   ` Srivatsa S. Bhat
2011-11-21 22:41                 ` Rafael J. Wysocki
2011-11-21 22:41                   ` Rafael J. Wysocki
2011-11-21 16:47   ` [PATCH v3] PM/Memory-hotplug: " Tejun Heo
2011-11-21 16:47     ` Tejun Heo
2011-11-21 17:12     ` Srivatsa S. Bhat
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 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.