On Fri, Mar 02, 2007 at 01:08:43AM +0900, YAMAMOTO Takashi wrote:

> > On Sun, Feb 25, 2007 at 05:21:22PM +0900, YAMAMOTO Takashi wrote:
> > 
> > > - why doesn't sched_changepri() change l_priority if it was < PUSER? 
> > 
> > If the LWP has received a priority boost while in the kernel and is waiting
> > to run it shouldn't get dropped until it has run.
> 
> thanks for explanation.
> isn't it better to have a flag to indicate if an lwp is boosted or not,
> and kill l_priority?

I think that would work. We still have a way for kernel code to change the
priority that does not follow a rule (tsleep) and we need somewhere to store
that priority. I'd like to change that, but it needs to be done with care.

> > 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?

Cheers,
Andrew