Hi We have an SMP behavioral decision to make and it isn't getting enough discussion.
With cluster scheduling, there are potentially multiple scheduler instances associated with non-overlapping subsets of cores. With affinity, a thread can be restricted to execute on a subset of the cores associated with a scheduler instance. There are operations to change the scheduler associated with a thread and the affinity of a thread. The question is whether changing affinity should be able to implicitly change the scheduler instance? I lean to no because affinity and scheduler changes should should be so rare in practical use that nothing should be implicit. Consider this scenario: Scheduler A: cores 0-1 Scheduler B: cores 2-3 Thread 1 is associated with Scheduler B and with affinity 2-3 can run on either processor scheduled by B. Thread 1 changes affinity 1-3. Should this change the scheduler, be an error, or just have an affinity for a core in the system that is not scheduled by this scheduler instance? If you look at the current code for _Scheduler_Set_affinity(), it looks like the current behavior is none of the above and appears to just be broken. Scheduler A's set affinity operation is invoked and Scheduler B is not informed that it no longer has control of Thread 1. -- 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
