All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Chen Gong <gong.chen@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	pavel@ucw.cz, lenb@kernel.org, ak@linux.intel.com, tj@kernel.org,
	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: Mon, 21 Nov 2011 13:52:40 +0530	[thread overview]
Message-ID: <4ECA0A50.7030502@linux.vnet.ibm.com> (raw)
In-Reply-To: <4ECA03DF.4000402@linux.intel.com>

On 11/21/2011 01:25 PM, Chen Gong wrote:
> [...]
>>
>> Actually, I think I have a better idea based on a key observation:
>> We are trying to acquire pm_mutex here. And if we block due to this,
>> we are *100% sure* that we are not going to run as long as hibernation
>> sequence is running, since hibernation releases pm_mutex only at the
>> very end, when everything is done.
>> And this means, this task is going to be blocked for much more longer
>> than what the freezer intends to achieve. Which means, freezing and
>> thawing doesn't really make a difference to this task!
>>
>> So, let's just ask the freezer to skip freezing us!! And everything
>> will be just fine!
>>
>> Something like:
>>
>> void lock_system_sleep(void)
>> {
>>     /* simplified freezer_do_not_count() */
>>     current->flags |= PF_FREEZER_SKIP;
>>
>>     mutex_lock(&pm_mutex);
>>
>> }
>>
>> void unlock_system_sleep(void)
>> {
>>     mutex_unlock(&pm_mutex);
>>
>>     /* simplified freezer_count() */
>>     current->flags&= ~PF_FREEZER_SKIP;
>>
>> }
>>
>> We probably don't want the restriction that freezer_do_not_count() and
>> freezer_count() work only for userspace tasks. So I have open coded
>> the relevant parts of those functions here.
>>
> 
> This new design looks clean and better than old one. I just curious how do
> you design your test environment? e.g. when hibernating is in progress,
> try to online some memories and wait for hibernation fails or succeeds?
> 

Hi Chen,

Thanks a lot for taking a look!

As I have indicated earlier in some of my mails, I am more concerned about
the API lock_system_sleep() than memory hotplug, because it is this *API*
that is buggy, not memory-hotplug. And going further, any other code planning
to use this API will be problematic. So our focus here, is to fix this *API*.

So, to test this API, I have written a kernel module that calls
lock_system_sleep() in its init code. Then I load/unload that module wildly
in a loop and simultaneously run hibernation tests using the 'pm_test'
framework. It is to be also noted that, the issue here is only with the initial
steps of hibernation, namely, related to freezer. Hence, pm_test framework
fits pretty well to debug these freezer issues. (And in fact, I have found that
this method is quite effective to test whether my patch fixes the issue or not.)

Thanks,
Srivatsa S. Bhat

--
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: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Chen Gong <gong.chen@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	pavel@ucw.cz, lenb@kernel.org, ak@linux.intel.com, tj@kernel.org,
	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: Mon, 21 Nov 2011 13:52:40 +0530	[thread overview]
Message-ID: <4ECA0A50.7030502@linux.vnet.ibm.com> (raw)
In-Reply-To: <4ECA03DF.4000402@linux.intel.com>

On 11/21/2011 01:25 PM, Chen Gong wrote:
> [...]
>>
>> Actually, I think I have a better idea based on a key observation:
>> We are trying to acquire pm_mutex here. And if we block due to this,
>> we are *100% sure* that we are not going to run as long as hibernation
>> sequence is running, since hibernation releases pm_mutex only at the
>> very end, when everything is done.
>> And this means, this task is going to be blocked for much more longer
>> than what the freezer intends to achieve. Which means, freezing and
>> thawing doesn't really make a difference to this task!
>>
>> So, let's just ask the freezer to skip freezing us!! And everything
>> will be just fine!
>>
>> Something like:
>>
>> void lock_system_sleep(void)
>> {
>>     /* simplified freezer_do_not_count() */
>>     current->flags |= PF_FREEZER_SKIP;
>>
>>     mutex_lock(&pm_mutex);
>>
>> }
>>
>> void unlock_system_sleep(void)
>> {
>>     mutex_unlock(&pm_mutex);
>>
>>     /* simplified freezer_count() */
>>     current->flags&= ~PF_FREEZER_SKIP;
>>
>> }
>>
>> We probably don't want the restriction that freezer_do_not_count() and
>> freezer_count() work only for userspace tasks. So I have open coded
>> the relevant parts of those functions here.
>>
> 
> This new design looks clean and better than old one. I just curious how do
> you design your test environment? e.g. when hibernating is in progress,
> try to online some memories and wait for hibernation fails or succeeds?
> 

Hi Chen,

Thanks a lot for taking a look!

As I have indicated earlier in some of my mails, I am more concerned about
the API lock_system_sleep() than memory hotplug, because it is this *API*
that is buggy, not memory-hotplug. And going further, any other code planning
to use this API will be problematic. So our focus here, is to fix this *API*.

So, to test this API, I have written a kernel module that calls
lock_system_sleep() in its init code. Then I load/unload that module wildly
in a loop and simultaneously run hibernation tests using the 'pm_test'
framework. It is to be also noted that, the issue here is only with the initial
steps of hibernation, namely, related to freezer. Hence, pm_test framework
fits pretty well to debug these freezer issues. (And in fact, I have found that
this method is quite effective to test whether my patch fixes the issue or not.)

Thanks,
Srivatsa S. Bhat


  reply	other threads:[~2011-11-21  8:23 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
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 [this message]
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=4ECA0A50.7030502@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=ak@linux.intel.com \
    --cc=gong.chen@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=tj@kernel.org \
    /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.