[RTEMS Project] #2510: Improve the SMP scheduler with arbitrary processor affinity support

RTEMS trac trac at rtems.org
Tue Jul 5 10:28:50 UTC 2016


#2510: Improve the SMP scheduler with arbitrary processor affinity support
-----------------------------+-------------------
 Reporter:  sebastian.huber  |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  5.0
Component:  SMP              |     Version:  4.11
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+-------------------

Comment (by darnir):

 == Processor Affinity Set Data Structures ==

 For the scheduler, we need to store the "processor affinity sets" in the
 nodes. I have reused the code for the Priority Affinity SMP Scheduler to
 add support for affinity sets. This uses the `cpu_set_t` data structure to
 store the affinity set information in `Scheduler_strong_APA_Node`. For the
 implementation of the algorithm, certain logical operations on the lists
 will be useful, especially, set intersection and set union. These
 operations are already supported by the `cpu_set_t` data structure, which
 is why I decided to stick with this structure instead of using
 `Processor_mask` or writing something new.

 == The Algorithm ==
 On arrival of a new task in the system, the
 `_Scheduler_strong_APA_Unblock` action will be triggered. The core of the
 algorithm, the iterative MVM solution will be implemented in this method
 itself. The output of the algorithm will be a mapping of processors to the
 thread that they are executing. This mapping will look something like
 this:

 `Thread_control *processor_to_task_mapping [ _SMP_Get_processor_count()
 ];`

 Where index 0 points to the thread executing on CPU 0, and so on.
 Initially, the entire array will point to the idle thread.

 Then, during the `Enqueue_ordered` operation, if `_get_lowest_scheduled()`
 returns a thread that has a lower priority than the arriving task, the
 case becomes trivial and we only need to carry out the standard forced
 migrations during the call to `move_from_scheduled_to_ready`.

 However, if the lowest scheduled task according to the affinity set has a
 higher priority than the arriving task, then we may need to carry out non-
 standard task migrations for the most optimal configuration. These
 migrations will be performed based on the MVM solution set created during
 the `Unblock` operation and will be implemented in the
 `_Scheduler_strong_APA_Insert_ready_fifo` method.

--
Ticket URL: <http://devel.rtems.org/ticket/2510#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list