Subject: Re: sched_changepri, and priority levels
To: Andrew Doran <ad@netbsd.org>
From: Matt Thomas <matt@3am-software.com>
List: tech-kern
Date: 03/06/2007 10:17:53
On Mar 6, 2007, at 9:19 AM, Andrew Doran wrote:

> On Tue, Mar 06, 2007 at 04:47:23AM +0900, YAMAMOTO Takashi wrote:
>
>>>>> Right now the drop in
>>>>> priority takes place in userret(). I think that should be moved  
>>>>> back into
>>>>> remrunqueue() once cpu_switch() is eliminated.
>>>>
>>>> i think userret() is a better place to unboost an lwp than  
>>>> remrunqueue().
>>>> if it was in remrunqueue() and we support in-kernel preemption,
>>>> an lwp can be preempted immediately after scheduled.
>>>
>>> Perhaps not remrunqueue() but at the point where the LWP is  
>>> picked and set
>>> running, so mi_switch(). What was I thinking is that we only want  
>>> to do
>>> kernel preemption for LWPs running with priority above the user/ 
>>> kernel
>>> level. Were you thinking of something else?
>>
>> i'm not sure in which case kernel preemption should happen.
>> i'm just wondering what's wrong with restoring it in userret().
>
> To change it in userret() we would need to acquire a lock or use an  
> atomic
> sequence, which is too expensive to do on every syscall. I think  
> your idea
> of having a flag that says "the LWP has kernel priority" could be a  
> good
> way to deal with this. Dropping the level in mi_switch() would be  
> another.
> Either way we would need to reset one of those before hitting  
> userret() in
> order to avoid the atomic operations.
>
> On the subject of priority levels, here is one suggestion and some  
> notes:
>
> 160 - 191       Interrupt (32)
> 96 - 160        Real time (64)
> 64 - 95         Kernel (32)
> 0 - 63          User (64)
>
> o FreeBSD positions "real time" below kernel, this is the other way  
> around.
> o FreeBSD also has the concept of idle priority levels. Is this  
> something
>   we also want? Are multiple levels required?
> o Low really does mean low, and high means high. Traditionally the  
> priority
>   has been "inverted".
> o It's fairly arbitrary!

I'd like a portion of kernel above real time as well at below.

192 - 255       Interrupt (64)
160 - 191	Kernel high (32)
96 - 159        Real time (64)
64 - 95         Kernel low (32)
0 - 63          User (64)