public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john cooper <john.cooper@timesys.com>
To: "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
Cc: dwalker@mvista.com, Esben Nielsen <simlo@phys.au.dk>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, sdietrich@mvista.com,
	rostedt@goodmis.org, john cooper <john.cooper@timesys.com>
Subject: Re: [PATCH] Abstracted Priority Inheritance for RT
Date: Thu, 02 Jun 2005 01:43:54 -0400	[thread overview]
Message-ID: <429E9C9A.1030507@timesys.com> (raw)
In-Reply-To: <F989B1573A3A644BAB3920FBECA4D25A036671E5@orsmsx407>

Perez-Gonzalez, Inaky wrote:
> It doesn't matter in which space the tasks are, a deadlock 
> condition can happen anywhere and that can easily lead to 
> infinite recursion/iteration (as bad). I seem to remember Ingo
> mentioning he had taken care of full transitivity (or maybe it
> was somebody else saying it).

That might have been me.  The last time I looked at this
specifically, full transitive promotion was being done in
the RT patch.  However unlike your attempt at scaling the
lock scope, the RT patch had one lock which coordinated
all mutex dependency traversals system wide.  This lock
must be speculatively acquired even before we ascertain
transitive promotion is required.

So it doesn't scale as well as it could in the case of
large count SMP systems.  The response was that of "get
it to work first and then we'll get it to scale" which
is reasonable.

When I looked at this sometime in the latter part of last
year I was concerned there was an inherent hierarchy violation
possible in the kernel for the case of fine grained (per-mutex)
locking when doing a transitive promotion traversal.   The
order of traversal is dependent upon the application's lock
acquisition sequence.  Ingo pointed out there shouldn't be a
kernel hierarchy inversion if it was first determined the
application itself wasn't violating it's own lock acquisition
hierarchy.  I recall this to be a valid and simplifying
assumption at the time though I haven't had cause to
follow up on the issue since then.

-john



-- 
john.cooper@timesys.com

  reply	other threads:[~2005-06-02  5:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-02  1:22 [PATCH] Abstracted Priority Inheritance for RT Perez-Gonzalez, Inaky
2005-06-02  5:43 ` john cooper [this message]
2005-06-03  0:54   ` Bill Huey
2005-06-03  1:10     ` Sven Dietrich
  -- strict thread matches above, loose matches on Subject: below --
2005-06-02  1:21 Perez-Gonzalez, Inaky
2005-06-02  0:52 linux
2005-06-02  0:10 Perez-Gonzalez, Inaky
2005-06-02  0:25 ` Daniel Walker
2005-06-01  2:57 Daniel Walker
2005-06-01  3:35 ` Steven Rostedt
2005-06-01  7:54 ` Ingo Molnar
2005-06-01 12:57   ` Daniel Walker
2005-06-01 14:07     ` Esben Nielsen
2005-06-01 23:58       ` Daniel Walker
2005-06-02  8:25         ` Esben Nielsen
2005-06-02 15:11           ` Daniel Walker
2005-06-02 15:18             ` Esben Nielsen
2005-06-02 17:31               ` Daniel Walker
2005-06-02 20:27                 ` Esben Nielsen
2005-06-02 21:50                   ` Daniel Walker
2005-06-03  9:08                     ` Esben Nielsen

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=429E9C9A.1030507@timesys.com \
    --to=john.cooper@timesys.com \
    --cc=dwalker@mvista.com \
    --cc=inaky.perez-gonzalez@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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