On 21-Dec-01 Bruce Evans wrote:
> On Fri, 21 Dec 2001, Luigi Rizzo wrote:
>> On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote:
>> > I think pri_native is just an implementation detail which shouldn't
>> > be used or visible to threads. It used used by the priority propagation
>> > mechanism to hold the original pri_level. Threads should just use their
>> > original priority (or a different one if they want to temporarily change
>> > thier priority). Even pri_level probably shouldn't be used or visible
>> > to threads.
>> the original priority should be somewhere and accessible,
>> either directly or through some function. Otherwise how
>> do we know what to pass to tsleep() ?
> It's whatever the thread set itself. There is no good way of setting
> this either (vm_pagezero() and poll_idle() hack it into
> td->td_ksegrp->kg_pri). Userland would use rtprio(2) instead.
> Unfortunately, this gives priorities in different units than the ones
> for tsleep().
pri_level is the current priority of the thread. The actual priority level is
going to move back into the thread and out of the KSE group so that tsleep and
priority propagation work properly, but pri_native, pri_user, and nice will
stay in the KSE group. The "normal" priorities for tsleep() are just a subset
of the priorities available to a thread. Thus, they are using the same unit,
but perhaps a wider range.
>> In any case I wonder if this is a bug new in -current; -stable
>> uses three separate data structures for realtime, user and idle tasks
>> so even specifying the wrong priority in tsleep should not cause
>> crossing classes there. -current has only one array, hence the
>> chance of doing the wrong thing.
> The 3 classes are a design bug in -stable. Crossing classes is sometimes
> right and 3 classes mainly make it harder and force triplication of code.
Agreed. In current we basically have one large priority array. At the top
(low priorities) are realtime kernel priorities including interrupt thread
priorities. Below those are other top-half kernel priorities including the
normal sleep priorities. Below that are real-time user priorities, followed by
time sharing user priorities, and finally idle user priorities.
Possibly real-time user priorities should move up into the real-time kernel
range, and it should be noted that the idle priorites are for idle kernel
threads, not just user threads (so sys/priority.h may need a bit of updating).
This is a simpler model esp. when you consider a thread of one priority class
blocking on a lock held by a thread of a "lower" priority class as you only
have to update pri_level for priority propagation rather than comparing classes
and having to manage that extra gunk.
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