From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <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: Mon, 21 Nov 2011 23:31:59 +0530 [thread overview]
Message-ID: <4ECA9217.7020205@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111121175242.GE15314@google.com>
On 11/21/2011 11:22 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Nov 21, 2011 at 10:34:40PM +0530, Srivatsa S. Bhat wrote:
>>>> I haven't tested this solution yet. Let me know if this solution looks
>>>> good and I'll send it out as a patch after testing and analyzing some
>>>> corner cases, if any.
>>
>> I tested this, and it works great! I'll send the patch in some time.
>
> Awesome.
>
>>> * I think it would be better to remove direct access to pm_mutex and
>>> use [un]lock_system_sleep() universally. I don't think hinging it
>>> on CONFIG_HIBERNATE_CALLBACKS buys us anything.
>>>
>>
>> Which direct access to pm_mutex are you referring to?
>> Other than suspend/hibernation call paths, I think mem-hotplug is the only
>> subsystem trying to access pm_mutex. I haven't checked thoroughly though.
>>
>> But yes, using lock_system_sleep() for mutually excluding some code path
>> from suspend/hibernation is good, and that is one reason why I wanted
>> to fix this API ASAP. But as long as memory hotplug is the only direct user
>> of pm_mutex, is it justified to remove the CONFIG_HIBERNATE_CALLBACKS
>> restriction and make it generic? I don't know...
>>
>> Or, are you saying that we should use these APIs even in suspend/hibernate
>> call paths? That's not such a bad idea either...
>
> Yeap, all. It's just confusing to have two different types of access
> to a single lock and I don't believe CONFIG_HIBERNATE_CALLBACKS is a
> meaningful optimization in this case.
>
Ok that sounds good, I'll send a separate patch for that.
Rafael, do you also agree that this would be better?
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: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <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: Mon, 21 Nov 2011 23:31:59 +0530 [thread overview]
Message-ID: <4ECA9217.7020205@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111121175242.GE15314@google.com>
On 11/21/2011 11:22 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Nov 21, 2011 at 10:34:40PM +0530, Srivatsa S. Bhat wrote:
>>>> I haven't tested this solution yet. Let me know if this solution looks
>>>> good and I'll send it out as a patch after testing and analyzing some
>>>> corner cases, if any.
>>
>> I tested this, and it works great! I'll send the patch in some time.
>
> Awesome.
>
>>> * I think it would be better to remove direct access to pm_mutex and
>>> use [un]lock_system_sleep() universally. I don't think hinging it
>>> on CONFIG_HIBERNATE_CALLBACKS buys us anything.
>>>
>>
>> Which direct access to pm_mutex are you referring to?
>> Other than suspend/hibernation call paths, I think mem-hotplug is the only
>> subsystem trying to access pm_mutex. I haven't checked thoroughly though.
>>
>> But yes, using lock_system_sleep() for mutually excluding some code path
>> from suspend/hibernation is good, and that is one reason why I wanted
>> to fix this API ASAP. But as long as memory hotplug is the only direct user
>> of pm_mutex, is it justified to remove the CONFIG_HIBERNATE_CALLBACKS
>> restriction and make it generic? I don't know...
>>
>> Or, are you saying that we should use these APIs even in suspend/hibernate
>> call paths? That's not such a bad idea either...
>
> Yeap, all. It's just confusing to have two different types of access
> to a single lock and I don't believe CONFIG_HIBERNATE_CALLBACKS is a
> meaningful optimization in this case.
>
Ok that sounds good, I'll send a separate patch for that.
Rafael, do you also agree that this would be better?
Thanks,
Srivatsa S. Bhat
next prev parent reply other threads:[~2011-11-21 18:02 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
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 [this message]
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=4ECA9217.7020205@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--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=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.