Date: Fri, 17 Dec 2010 09:44:27 -0500 From: John Baldwin <jhb@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: arch@freebsd.org, Sergey Babkin <babkin@verizon.net> Subject: Re: Realtime thread priorities Message-ID: <201012170944.27250.jhb@freebsd.org> In-Reply-To: <4D0B6E54.2070802@freebsd.org> References: <201012101050.45214.jhb@freebsd.org> <201012170752.06540.jhb@freebsd.org> <4D0B6E54.2070802@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012170944.27250.jhb>