From: Matt Helsley <matthltc@linux.vnet.ibm.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Colin Cross <ccross@android.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rjw@sisk.pl>,
arve@android.com, Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Matthew Helsley <matthltc@us.ibm.com>
Subject: Re: [PATCH 07/10] futex: use freezable blocking call
Date: Thu, 2 May 2013 12:52:33 -0700 [thread overview]
Message-ID: <20130502195233.GC24627@us.ibm.com> (raw)
In-Reply-To: <517EF9AB.8080508@linux.intel.com>
On Mon, Apr 29, 2013 at 03:52:27PM -0700, Darren Hart wrote:
> Colin,
>
> I don't know anything about when or when not to use freezable*, and I
> suspect that may be true for others as well. A more complete
> description of why it's acceptable here in the commit log might help
> expedite acceptance.
>
>
> Matt,
>
> I have a vague memory of discussing something similar to this with you.
> Do you see any potential problems here?
Re: vague memories: We discussed futexes in the context of the old
checkpoint/restart patch series (<= 2.6.32).
This change looks correct to me.
> --
> Darren
>
> On 04/29/2013 02:45 PM, Colin Cross wrote:
> > Avoid waking up every thread sleeping in a futex_wait call during
> > suspend and resume by calling a freezable blocking call.
(in addition to suspend/resume: freeze/thaw via the cgroup freezer.
I'm going to call it freeze/thaw since that should cover both cases..)
Here's my shot at explaining what I *think* the commit is supposed fix:
I imagine that before this patch on a highly-contended futex there
could be a thundering herd during freeze/thaw -- the wakeups are
*likely* to be painful because lots of tasks could be woken from the
schedule() call by the freezer only to find that the futex state hasn't
changed.
With this change the freezer won't wake these tasks up because the
FREEZER_SKIP flag is set while in the schedule() call and thus the
thundering herd won't be triggered by the freezer.
Cheers,
-Matt Helsley
next prev parent reply other threads:[~2013-05-03 22:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 21:45 [PATCH 00/10] optimize freezing tasks by reducing task wakeups Colin Cross
2013-04-29 21:45 ` [PATCH 01/10] freezer: shorten freezer sleep time using exponential backoff Colin Cross
2013-05-02 12:28 ` Pavel Machek
2013-04-29 21:45 ` [PATCH 02/10] freezer: skip waking up tasks with PF_FREEZER_SKIP set Colin Cross
2013-04-29 21:51 ` Tejun Heo
2013-04-29 21:57 ` Tejun Heo
2013-04-29 22:02 ` Colin Cross
2013-04-29 22:08 ` Tejun Heo
2013-04-29 22:16 ` Tejun Heo
2013-04-30 11:48 ` Rafael J. Wysocki
2013-04-30 17:10 ` Oleg Nesterov
2013-04-30 17:15 ` Oleg Nesterov
2013-04-29 21:45 ` [PATCH 03/10] freezer: add new freezable helpers using freezer_do_not_count() Colin Cross
2013-05-02 12:48 ` Pavel Machek
2013-05-02 13:05 ` Oliver Neukum
2013-05-02 13:46 ` Pavel Machek
2013-05-02 17:05 ` Colin Cross
2013-05-03 14:00 ` Pavel Machek
2013-04-29 21:45 ` [PATCH 04/10] binder: use freezable blocking calls Colin Cross
2013-04-29 21:45 ` [PATCH 05/10] epoll: use freezable blocking call Colin Cross
2013-04-29 21:45 ` [PATCH 06/10] select: " Colin Cross
2013-04-29 21:45 ` [PATCH 07/10] futex: " Colin Cross
2013-04-29 22:52 ` Darren Hart
2013-04-29 23:46 ` Colin Cross
2013-05-02 19:52 ` Matt Helsley [this message]
2013-04-29 21:45 ` [PATCH 08/10] nanosleep: " Colin Cross
2013-04-29 21:45 ` [PATCH 09/10] sigtimedwait: " Colin Cross
2013-04-30 16:38 ` Oleg Nesterov
2013-04-30 16:56 ` Oleg Nesterov
2013-04-30 16:58 ` Colin Cross
2013-04-30 17:00 ` Oleg Nesterov
2013-04-29 21:45 ` [PATCH 10/10] af_unix: use freezable blocking calls in read Colin Cross
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=20130502195233.GC24627@us.ibm.com \
--to=matthltc@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=ccross@android.com \
--cc=dvhart@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=rdunlap@infradead.org \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/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).