On 20-Dec-01 Luigi Rizzo wrote:
> On Thu, Dec 20, 2001 at 11:13:27AM -0800, Peter Wemm wrote:
> ...
>> Excellent catch!  This particular problem was one of the main reasons
>> why this is still defaulting to 'off'.  I have a couple of other changes
>> to it pending commit to fix some of Bruce's complaints, but I hadn't
>> noticed the cause of this.
>> Part of the problem is that tsleep temporarily elevates the priority for
>> wakeup, and it is normally returned back to "normal" level when the process
>> returns to userland (see the *_userpri stuff).
> ah, ok, kernel threads never return to userland...
> so, i presume one should also make sure that after the process is
> scheduled, the priority is restored to the 'native' level; this
> should also solve the problem with the priority propagation mechanism
> (though... I have the feeling that if you have nested locks, this
> cannot scale...)

Priority propagation will already handle things ok.  We drop to pri_native
after we drop a lock (although if we still hold a contested lock we bump our
priority to the min(nativepri, highest priority of threads on contested locks
we hold and drop to nativepri after dropping the last contested lock). 
However, kthreads should tsleep() with their current priority, not PPAUSE.


John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to