> 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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:24 EST