Hi
Questions first:
+ The affinity mask must be non-empty. This means a thread must
be able to be scheduled on some processor. With cluster scheduling,
a scheduler implementation would only be associated with a subset
of processors. The affinity can't be set such that the thread can't be
scheduled by this scheduler instance. How can a scheduler instance
know which processors it is associated with?
+ Similarly, changing scheduler for a thread dynamically should not
allow the above to be violated. The thread must have affinity for one
or more of the cores. How can this be done?
Design thoughts:
+ Change priority is very careful to avoid rescheduling an executing
thread. Is this optimization worth the trouble for affinity? I really have
trouble seeing it be worth the trouble. Changing priority is fairly
common thanks to priority inheritance and ceiling. Changing affinity
should be pretty uncommon since I think it is an application design
parameter.
+ If this optimization is not worth the trouble, then
_Scheduler_Set_affinity()
should be able to do something like this like when you change the
scheduler in _Scheduler_Set():
validate new affinity // includes can run on subset for this
scheduler
if ! changed return
_Thread_Set_state( the_thread, STATES_MIGRATING );
update affinity
_Thread_Clear_state( the_thread, STATES_MIGRATING );
Comments?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
