mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@mvista.com>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, sdietrich@mvista.com,
	rostedt@goodmis.org, inaky.perez-gonzalez@intel.com
Subject: Re: [PATCH] Abstracted Priority Inheritance for RT
Date: Thu, 02 Jun 2005 14:50:28 -0700	[thread overview]
Message-ID: <1117749028.20350.12.camel@dhcp153.mvista.com> (raw)
In-Reply-To: <Pine.OSF.4.05.10506022017400.3853-100000@da410.phys.au.dk>

On Thu, 2005-06-02 at 22:27 +0200, Esben Nielsen wrote:

> But right now the following ideas spring to my mind:
> If it is to solve the problem of having a callback wrap every use
> in macroes and use the TYPE_EQUAL() to expclicit call the right function.
> Only if the explicit type is unknown in the macro use the callback. That
> should optimize stuff a little bit.. Just a wild idea.

It's a little hard to do that. It's basically the situation you have
below, there is no way to know what "waiter" is at compile time, so you
can't really do the TYPE_EQUAL() trick on "get_next_waiter" .

I have "waiter->waiter_changed_prio()" which results in the same
problem. There is no way to know what "type" waiter is at compile
time .. 


> If it is explicitly for PI you can do a thing like
>  waiter->get_next_waiter();
> to resolve the chain of waiters. Then you can have the PI algotithm work
> iteratively without knowing the explicit kind of lock involved.

This is essentially what I have now, but it's also what I'm unhappy
with. The only reason that I don't like this method is that it's a
little slow .. I don't mind keeping it as long as no better way presents
itself. 

Daniel


  reply	other threads:[~2005-06-02 21:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2005-06-03  9:08                     ` Esben Nielsen
2005-06-02  0:10 Perez-Gonzalez, Inaky
2005-06-02  0:25 ` Daniel Walker
2005-06-02  0:52 linux
2005-06-02  1:21 Perez-Gonzalez, Inaky
2005-06-02  1:22 Perez-Gonzalez, Inaky
2005-06-02  5:43 ` john cooper
2005-06-03  0:54   ` Bill Huey
2005-06-03  1:10     ` Sven Dietrich

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=1117749028.20350.12.camel@dhcp153.mvista.com \
    --to=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

all inboxes | Powered by JetHome®