Changeset a6a1f72 in rtems-docs


Ignore:
Timestamp:
Feb 1, 2017, 12:23:14 PM (3 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
5, master
Children:
9de1be6
Parents:
a238912
Message:

c-user: Update task migration

File:
1 edited

Legend:

Unmodified
Added
Removed
  • c-user/symmetric_multiprocessing_services.rst

    ra238912 ra6a1f72  
    129129
    130130With more than one processor in the system tasks can migrate from one processor
    131 to another.  There are three reasons why tasks migrate in RTEMS.
    132 
    133 - The scheduler changes explicitly via ``rtems_task_set_scheduler()`` or
    134   similar directives.
     131to another.  There are four reasons why tasks migrate in RTEMS.
     132
     133- The scheduler changes explicitly via
     134  :ref:`rtems_task_set_scheduler() <rtems_task_set_scheduler>` or similar
     135  directives.
     136
     137- The task processor affinity changes explicitly via
     138  :ref:`rtems_task_set_affinity() <rtems_task_set_affinity>` or similar
     139  directives.
    135140
    136141- The task resumes execution after a blocking operation.  On a priority based
     
    139144
    140145- The task moves temporarily to another scheduler instance due to locking
    141   protocols like *Migratory Priority Inheritance* or the *Multiprocessor
    142   Resource Sharing Protocol*.
     146  protocols like the :ref:`MrsP` or the :ref:`OMIP`.
    143147
    144148Task migration should be avoided so that the working set of a task can stay on
    145149the most local cache level.
    146 
    147 The current implementation of task migration in RTEMS has some implications
    148 with respect to the interrupt latency.  It is crucial to preserve the system
    149 invariant that a task can execute on at most one processor in the system at a
    150 time.  This is accomplished with a boolean indicator in the task context.  The
    151 processor architecture specific low-level task context switch code will mark
    152 that a task context is no longer executing and waits that the heir context
    153 stopped execution before it restores the heir context and resumes execution of
    154 the heir task.  So there is one point in time in which a processor is without a
    155 task.  This is essential to avoid cyclic dependencies in case multiple tasks
    156 migrate at once.  Otherwise some supervising entity is necessary to prevent
    157 life-locks.  Such a global supervisor would lead to scalability problems so
    158 this approach is not used.  Currently the thread dispatch is performed with
    159 interrupts disabled.  So in case the heir task is currently executing on
    160 another processor then this prolongs the time of disabled interrupts since one
    161 processor has to wait for another processor to make progress.
    162 
    163 It is difficult to avoid this issue with the interrupt latency since interrupts
    164 normally store the context of the interrupted task on its stack.  In case a
    165 task is marked as not executing we must not use its task stack to store such an
    166 interrupt context.  We cannot use the heir stack before it stopped execution on
    167 another processor.  So if we enable interrupts during this transition we have
    168 to provide an alternative task independent stack for this time frame.  This
    169 issue needs further investigation.
    170150
    171151Clustered Scheduling
Note: See TracChangeset for help on using the changeset viewer.