From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: [ANNOUNCE] 3.2.9-rt17
Date: Fri, 9 Mar 2012 01:33:08 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1203090124160.2742@ionos> (raw)
In-Reply-To: <1331241940.25686.502.camel@gandalf.stny.rr.com>
On Thu, 8 Mar 2012, Steven Rostedt wrote:
> On Thu, 2012-03-08 at 22:20 +0100, Peter Zijlstra wrote:
>
> > Now put the thing on 2 cpus and both tasks can endlessly chase each
> > other's tail, no?
>
> How would this be different than what mainline does? When the lock is
> released, it will wake up the other task.
Nonsense. That code is not causing any headache in mainline simply
because the lock holder cannot be preempted. So the contention case
runs on different cpus. On RT the failure case is when the trylocker
preempts the lock holder, which cannot be moved to a different cpu due
to the implicit migrate disable. Aside of that cpu_relax() and ticket
locks are there for a reason. They allow the other cpu to make
progress instead of allowing the trylocking cpu to monopolize the
cache line forever.
The only case where mainline can fail is when a high prio task does a
mutex_trylock() loop and the mutex owner and the trylocker are pinned
on the same core. Though I have not yet found code like that, but I
have not looked too hard either :)
It's a simple RT problem, which has been there forever, but obviously
nobody did stress tests such code pathes on UP systems or if someone
did he was not able to trigger it. On SMP this was not a big issue
when task migration was almost always enabled. Due to the implicit
migrate disable withing spinlocked regions we just made it more likely
to happen.
Thanks,
tglx
next prev parent reply other threads:[~2012-03-09 0:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 21:49 Thomas Gleixner
2012-03-08 18:23 ` Steven Rostedt
2012-03-08 18:28 ` Peter Zijlstra
2012-03-08 18:42 ` Steven Rostedt
2012-03-08 19:39 ` Peter Zijlstra
2012-03-08 20:10 ` Steven Rostedt
2012-03-08 20:26 ` Peter Zijlstra
2012-03-08 21:08 ` Steven Rostedt
2012-03-08 21:20 ` Peter Zijlstra
2012-03-08 21:25 ` Steven Rostedt
2012-03-08 21:28 ` Peter Zijlstra
2012-03-08 21:36 ` Steven Rostedt
2012-03-08 21:37 ` Peter Zijlstra
2012-03-08 21:44 ` Steven Rostedt
2012-03-08 21:54 ` Peter Zijlstra
2012-03-08 22:13 ` Steven Rostedt
2012-03-08 22:20 ` Peter Zijlstra
2012-03-08 22:27 ` Steven Rostedt
2012-03-09 4:17 ` Steven Rostedt
2012-03-09 0:33 ` Thomas Gleixner [this message]
2012-03-09 3:08 ` Steven Rostedt
2012-03-09 0:20 ` Thomas Gleixner
2012-03-09 2:50 ` Steven Rostedt
2012-03-09 10:23 ` Thomas Gleixner
2012-03-09 12:51 ` Steven Rostedt
2012-03-08 19:48 ` Peter Zijlstra
2012-03-08 20:01 ` Steven Rostedt
2012-03-08 20:08 ` Peter Zijlstra
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=alpine.LFD.2.02.1203090124160.2742@ionos \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®