Re: [PATCH] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Daniel Walker <dwalker@...>
Cc: <linux-rt-users@...>, <linux-kernel@...>
Date: Wednesday, August 1, 2007 - 1:32 pm

On Wed, 2007-08-01 at 08:55 -0700, Daniel Walker wrote:

I can live with that.


Right ;)  That's all I am really saying, but its not a big deal.


Cool!  I haven't looked at the patches in depth yet, but perhaps that
concept should be revisited.


Well, not necessarily.  I think your first instinct was right.  Really
any form of waiting can potentially be subject to inversion, IMHO.
Waiting for a mutex is an obvious form, and also easy to solve since you
have clear delineation between the waiters (and their priorities) and
the resource holder.  

However, inversion can happen any time you are waiting on a resource
regardless of the blocking mechanism...for instance, waiting on a
wait_queue.  Consider the situation of three RT tasks A, B, C.  A is the
highest, C the lowest.  Assume C is a threaded IRQ handler for, say,
diskio, and C will signal a wait_queue when IO completes.  In this
scenario, A can get inverted behind B if it does diskio.  (In fact, I
think someone was reporting a similar problem on the list last week, and
the response was that we don't support that yet...I would like to change
that :).

The problem with something like a wait_queue, as previously mentioned,
is you don't have a clear way to delineate who should get PI boosted.  I
am wondering if we can put our heads together and come up with a
comprehensive solution to this problem (even if it only works in certain
situations..e.g. threads that explicitly register with a waitqueue,
etc).

The solution here might be as simple as the previously mentioned
registration API, it might be something that can be done automatically
in the infrastructure, or it might be something along the lines of
converting more things over to use rt_mutex?  I don't know what the
answer will be yet.  All have their challenges.  But I do think its a
problem worth solving.

I think the workqueue stuff we are doing is really the first step in
this direction...but really some parts of that work are just special
casing one form of the "wait_queue" scenario.  I would like to
generalize this going forward.


I totally agree that what the workqueues are currently doing in our
patches are just a subset of PI.  But I absolutely think there are
potential users of at least some of PI like facilities other than just
mutexes.

I appreciate your review, discussion, and contribution on this matter,
Daniel.  Thank you!  I will take a look at your PI patches to see if I
think it aligns with my current thoughts.

-Greg

-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] RT: Add priority-queuing and priority-inheritanc..., Gregory Haskins, (Wed Aug 1, 1:32 pm)