RE: [patch] "HT scheduler", sched-2.5.63-B3

[Perez-Gonzalez, Inaky]

> On Fri, 7 Mar 2003, Perez-Gonzalez, Inaky wrote:
> 
> > Question: does this apply also to tasks that are current on another CPU
> > other than the local?
> >
> > Or, can I change the prio of a task that is current on another CPU
> > directly and then set_tsk_need_resched()? Or I also have to unqueue it
> > first?
> 
> any task must be unqueued before changing its priority - the runqueues are
> indexed by the priority field. The special case in wakeup is that 'p' is
> not on any runqueues (hence the wakeup ...), so we have a cheap
> opportunity there to fix up priority. But it's not a problem for an
> already running process either - it needs to be requeued.

Thanks, I was suspecting that [when something makes full sense, it is
easy to suspect it :)].

How friendly would you be to a hook into setscheduler()? I have this 
same problem with real-time futexes, specially wrt to effective priority 
in priority-inheritance & prio-protection. Basically, I need to know 
right away when a waiting tasks' priority has been changed so I can
properly reposition it into the waiting list.

As well, whenever I change the priority of an active/running task, it needs
to activate the hooks (for my proof-of-concept I did that manually; however,
it is limited and non-extensible), and I am looking into unfolding
setscheduler() into setscheduler() and do_setscheduler(), the later taking
the task struct, policy and priority to set, so that it can be called
from inside the kernel. setscheduler() would only do the user-space 
stuff handling.

Would that be ok with you?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)