From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
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 v2] PM/Memory-hotplug: Avoid task freezing failures
Date: Wed, 16 Nov 2011 23:54:04 +0530 [thread overview]
Message-ID: <4EC3FFC4.2010904@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111116174302.GD18919@google.com>
On 11/16/2011 11:13 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 16, 2011 at 10:52:14PM +0530, Srivatsa S. Bhat wrote:
>> So, honestly I didn't understand what is wrong with the approach of this
>> patch. And as a consequence, I don't see why we should wait to fix this
>> issue.
>>
>> [And by the way recently I happened to see yet another proposed patch
>> trying to make use of this API. So wouldn't it be better to fix this
>> ASAP, especially when we have a fix readily available?]
>
> It just doesn't look like a proper solution. Nothing guarantees
> freezing will happen soonish. Not all pm operations involve freezer.
> The exclusion is against mem hotplug at this point, right? I don't
> think it's a good idea to add such hack to fix a mostly theoretical
> problem and it's actually quite likely someone would be scratching
> head trying to figure out why the hell the CPU was hot spinning while
> the system is trying to enter one of powersaving mode (we had similar
> behavior in freezer code a while back and it was ugly).
>
> So, let's either fix it properly or leave it alone.
>
Ok, so by "proper solution", are you referring to a totally different
method (than grabbing pm_mutex) to implement mutual exclusion between
subsystems and suspend/hibernation, something like the suspend blockers
stuff and friends?
Or are you hinting at just the existing code itself being fixed more
properly than what this patch does, to avoid having side effects like
you pointed out?
I am just trying to figure out what would be the best way to proceed here.
By the way I consider it lucky that we have spotted this bug before we
actually hit it.. So I would really love to get this fixed before it
comes back to haunt us in the future ;-)
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>
next prev parent reply other threads:[~2011-11-16 18:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 11:55 Srivatsa S. Bhat
2011-11-16 16:26 ` Tejun Heo
2011-11-16 17:22 ` Srivatsa S. Bhat
2011-11-16 17:43 ` Tejun Heo
2011-11-16 18:24 ` Srivatsa S. Bhat [this message]
2011-11-16 18:41 ` Tejun Heo
2011-11-16 19:05 ` Srivatsa S. Bhat
2011-11-16 21:47 ` 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=4EC3FFC4.2010904@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox