Scheduler Set Affinity Design Thoughts
Joel Sherrill
joel.sherrill at OARcorp.com
Fri May 16 17:48:25 UTC 2014
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.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the devel
mailing list