Realtime thread priorities

John Baldwin jhb at
Fri Dec 17 14:44:29 UTC 2010

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

More information about the freebsd-arch mailing list