From: Ingo Molnar <mingo@elte.hu>
To: "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
Cc: Sven-Thorsten Dietrich <sdietrich@mvista.com>,
Daniel Walker <dwalker@mvista.com>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Esben Nielsen <simlo@phys.au.dk>, Joe Korty <joe.korty@ccur.com>
Subject: Re: [PATCH] Priority Lists for the RT mutex
Date: Mon, 11 Apr 2005 10:57:37 +0200 [thread overview]
Message-ID: <20050411085737.GA11109@elte.hu> (raw)
In-Reply-To: <F989B1573A3A644BAB3920FBECA4D25A02F64C65@orsmsx407>
* Perez-Gonzalez, Inaky <inaky.perez-gonzalez@intel.com> wrote:
> Let me re-phrase then: it is a must have only on PI, to make sure you
> don't have a loop when doing it. Maybe is a consequence of the
> algorithm I chose. -However- it should be possible to disable it in
> cases where you are reasonably sure it won't happen (such as kernel
> code). In any case, AFAIR, I still did not implement it.
are there cases where userspace wants to disable deadlock-detection for
its own locks?
the deadlock detector in PREEMPT_RT is pretty much specialized for
debugging (it does all sorts of weird locking tricks to get the first
deadlock out, and to really report it on the console), but it ought to
be possible to make it usable for userspace-controlled locks as well.
Ingo
next prev parent reply other threads:[~2005-04-11 8:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 8:49 [PATCH] Priority Lists for the RT mutex Perez-Gonzalez, Inaky
2005-04-11 8:57 ` Ingo Molnar [this message]
2005-04-11 22:17 ` Bill Huey
2005-04-12 20:35 ` Esben Nielsen
-- strict thread matches above, loose matches on Subject: below --
2005-05-06 18:13 Perez-Gonzalez, Inaky
2005-05-07 7:25 ` Oleg Nesterov
2005-05-09 7:30 ` Ingo Molnar
2005-05-09 8:08 ` Oleg Nesterov
2005-05-09 9:11 ` Ingo Molnar
2005-05-09 14:32 ` Oleg Nesterov
2005-05-09 18:13 ` Daniel Walker
2005-05-09 19:21 ` Steven Rostedt
2005-05-09 21:29 ` Daniel Walker
2005-05-09 22:15 ` Daniel Walker
2005-05-09 14:07 ` Daniel Walker
2005-05-06 9:05 Oleg Nesterov
2005-05-06 11:13 ` Oleg Nesterov
2005-05-06 18:56 ` Daniel Walker
2005-04-12 0:36 Perez-Gonzalez, Inaky
2005-04-11 23:28 Perez-Gonzalez, Inaky
2005-04-12 0:27 ` Bill Huey
2005-04-11 22:31 Perez-Gonzalez, Inaky
2005-04-11 23:11 ` Bill Huey
2005-04-11 9:03 Perez-Gonzalez, Inaky
2005-04-11 8:27 Perez-Gonzalez, Inaky
2005-04-11 8:42 ` Ingo Molnar
2005-04-08 23:05 Perez-Gonzalez, Inaky
2005-04-08 21:25 Perez-Gonzalez, Inaky
2005-04-08 22:53 ` Daniel Walker
2005-04-07 17:52 Daniel Walker
2005-04-08 6:28 ` Ingo Molnar
2005-04-08 8:05 ` Sven-Thorsten Dietrich
2005-04-10 11:09 ` Ingo Molnar
2005-04-12 17:56 ` Daniel Walker
2005-04-08 17:11 ` Daniel Walker
2005-04-10 10:53 ` Ingo Molnar
2005-04-11 16:19 ` Daniel Walker
2005-04-12 18:37 ` Paul E. McKenney
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=20050411085737.GA11109@elte.hu \
--to=mingo@elte.hu \
--cc=dwalker@mvista.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sdietrich@mvista.com \
--cc=simlo@phys.au.dk \
/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