From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Mel Gorman <mgorman@suse.de>, Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Chris Mason <chris.mason@fusionio.com>, Chris Mason <clm@fb.com>,
LKML <linux-kernel@vger.kernel.org>,
Sebastian Sewior <bigeasy@linutronix.de>
Subject: Re: [RFC PATCH] futex: Remove requirement for lock_page in get_futex_key
Date: Tue, 24 Feb 2015 17:55:40 +0100 [thread overview]
Message-ID: <20150224165540.GA32264@breakpoint.cc> (raw)
In-Reply-To: <alpine.DEB.2.02.1402111650250.21991@ionos.tec.linutronix.de>
On 2014-02-11 16:51:55 [+0100], Thomas Gleixner wrote:
> On Wed, 30 Oct 2013, Mel Gorman wrote:
> > On Wed, Oct 30, 2013 at 09:45:31AM +0100, Thomas Gleixner wrote:
> > > On Tue, 29 Oct 2013, Mel Gorman wrote:
> > > > Patch boots and futextest did not explode but I did no comparison
> > > > performance tests. Thomas, do you have details of the workload that
> > > > drove you to examine this problem? Alternatively, can you test it and
> > > The scenario is simple. All you need is a PSHARED futex.
> > >
> > > Task A
> > > get_futex_key()
> > > lock_page()
> > >
> > > ---> preemption
> > >
> > Do please. I'd rather not sink time into trying to reproduce a hypothetical
> > problem when people who are already familiar with it can provide better
> Took some time, but the folks finally came around to give it a try and
> it fixes their problem. I did not explode either, but I doubt, that
> their workload can trigger any of the corner cases.
I just stumbled uppon this patch and now I am curious about its status.
tglx said that it solves the problem in question (with doubt of
triggering all the corner cases). Chris pointed out that moving
put_page() might be worth doing.
Sebastian
prev parent reply other threads:[~2015-02-24 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 17:38 [RFC PATCH] futex: Remove requirement for lock_page in get_futex_key Mel Gorman
2013-10-29 18:48 ` Chris Mason
2013-10-30 8:57 ` Peter Zijlstra
2013-11-01 9:24 ` Mel Gorman
2013-10-30 8:45 ` Thomas Gleixner
2013-10-30 9:26 ` Mel Gorman
2014-02-11 15:51 ` Thomas Gleixner
2015-02-24 16:55 ` Sebastian Andrzej Siewior [this message]
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=20150224165540.GA32264@breakpoint.cc \
--to=sebastian@breakpoint.cc \
--cc=bigeasy@linutronix.de \
--cc=chris.mason@fusionio.com \
--cc=clm@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.