Realtime thread priorities

[John Baldwin]

On Friday, December 17, 2010 9:06:12 am David Xu wrote:
> John Baldwin wrote:
> > Yes, we do not do priority lending for sleep locks, and to date we never
> > have.  This is not a new problem and moving RT priority higher is not
> > introducing any _new_ problems.  However, it does bring _new_ functionality
> > that some people need.  Just because you don't need it doesn't mean it isn't
> > important.
> >
> > Don't let the perfect be the enemy of the good.
> >
> >   
> I guess that your real requirement is preempting at user boundary
> for static priority thread, however current code does not. I doubt that
> preempting in kernel path which holding an unknown lock has any
> visible benefit for your application. Yes, perfect is not the enemy but
> the goal, isn't mutex with priority propagating for perfect ?

Actually, in my case what I need is for some other process that holds a lock
in the kernel that I need to run as soon as possible.  I would be fine with
preempting a different thread in the kernel so the thread holding the lock I
need can run.  It is true that in my case I don't really care about the
priority of my thread since it runs on a dedicated CPU.  What I really care
about is the priority it lends to other threads.  I need that to be higher
than just about everything else.

In my case I could even benefit from priority_propagation() sending an IPI
to a remote CPU so the thread I just lent priority to can run, but that is
somewhat unique due to my use of cpusets.  Without a restricted cpuset you
wouldn't need that since the running thread is about to block and will run
the lock holder as the next thread if needed.

-- 
John Baldwin