Messages in this thread | | | Date | Thu, 2 May 2013 12:52:33 -0700 | From | Matt Helsley <> | Subject | Re: [PATCH 07/10] futex: use freezable blocking call |
| |
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
| |