sched_userret priority adjustment patch for sched_4bsd

[Stephan Uphoff]

On Mon, 2004-09-27 at 18:10, Julian Elischer wrote:
> Stephan Uphoff wrote:
> 
> >On Mon, 2004-09-27 at 14:43, John Baldwin wrote:
> >  
> >
> >>>>@@ -272,7 +272,7 @@
> >>>> {
> >>>>
> >>>>        mtx_assert(&sched_lock, MA_OWNED);
> >>>>-       if (td->td_priority < curthread->td_priority)
> >>>>+       if (td->td_priority < curthread->td_ksegrp->kg_user_pri)
> >>>>                curthread->td_flags |= TDF_NEEDRESCHED;
> >>>> }
> >>>>        
> >>>>
> 
> in sched_userret() we do:
>         kg = td->td_ksegrp;
>         if (td->td_priority != kg->kg_user_pri) {
>                 mtx_lock_spin(&sched_lock);
>                 td->td_priority = kg->kg_user_pri;
>                 mtx_unlock_spin(&sched_lock);
>         }
> 
> but we don't actually take any action in the case where the thread is 
> heading out to userland with
> a priority of less importance than a waiting thread. That happens in 
> AST() where we also set it down
> but only in the  case of TDF_NEEDRESCHED being set.
> 
> it would make more sense to ALWAYS to the TDF_NEEDRESCHED clause, in 
> userret()
> based on the user priority... i.e. the priority would be reduced going 
> to userland.
> Unfortunatly this would stop one of the reasons to for priorityu 
> raisning in BSD.
> 
> The priority of a thread that waits for IO is raised not only to make it 
> start again in the kernel
> as an interactive thread, but also so that it can run into userland too 
> and get some priority
> for actually USING the new data/input..

Thanks - I wasn't aware of this.
Isn't there a high potential for abuse?
A client/server programs constantly refreshing priority by waiting for
requests/replies comes to mind. If a client/server pair constantly talks
to each other they could eat a lot of cpu time.
I have to think about this some more.

	Stephan