Scheduler Set Affinity Design Thoughts

[Joel Sherrill]

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