Changeset 38b59a6 in rtems for doc


Ignore:
Timestamp:
05/02/14 08:31:09 (10 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
4.11, 5, master
Children:
6c36946f
Parents:
58444f7
git-author:
Sebastian Huber <sebastian.huber@…> (05/02/14 08:31:09)
git-committer:
Sebastian Huber <sebastian.huber@…> (05/07/14 12:26:28)
Message:

score: Implement forced thread migration

The current implementation of task migration in RTEMS has some
implications with respect to the interrupt latency. It is crucial to
preserve the system invariant that a task can execute on at most one
processor in the system at a time. This is accomplished with a boolean
indicator in the task context. The processor architecture specific
low-level task context switch code will mark that a task context is no
longer executing and waits that the heir context stopped execution
before it restores the heir context and resumes execution of the heir
task. So there is one point in time in which a processor is without a
task. This is essential to avoid cyclic dependencies in case multiple
tasks migrate at once. Otherwise some supervising entity is necessary to
prevent life-locks. Such a global supervisor would lead to scalability
problems so this approach is not used. Currently the thread dispatch is
performed with interrupts disabled. So in case the heir task is
currently executing on another processor then this prolongs the time of
disabled interrupts since one processor has to wait for another
processor to make progress.

It is difficult to avoid this issue with the interrupt latency since
interrupts normally store the context of the interrupted task on its
stack. In case a task is marked as not executing we must not use its
task stack to store such an interrupt context. We cannot use the heir
stack before it stopped execution on another processor. So if we enable
interrupts during this transition we have to provide an alternative task
independent stack for this time frame. This issue needs further
investigation.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/smp.t

    r58444f7 r38b59a6  
    212212affinity.
    213213
     214@subsection Task Migration
     215
     216@cindex task migration
     217@cindex thread migration
     218
     219With more than one processor in the system tasks can migrate from one processor
     220to another.  There are three reasons why tasks migrate in RTEMS.
     221
     222@itemize @bullet
     223@item The scheduler changes explicitly via @code{rtems_task_set_scheduler()} or
     224similar directives.
     225@item The task resumes execution after a blocking operation.  On a priority
     226based scheduler it will evict the lowest priority task currently assigned to a
     227processor in the processor set managed by the scheduler instance.
     228@item The task moves temporarily to another scheduler instance due to locking
     229protocols like @cite{Migratory Priority Inheritance} or the
     230@cite{Multiprocessor Resource Sharing Protocol}.
     231@end itemize
     232
     233Task migration should be avoided so that the working set of a task can stay on
     234the most local cache level.
     235
     236The current implementation of task migration in RTEMS has some implications
     237with respect to the interrupt latency.  It is crucial to preserve the system
     238invariant that a task can execute on at most one processor in the system at a
     239time.  This is accomplished with a boolean indicator in the task context.  The
     240processor architecture specific low-level task context switch code will mark
     241that a task context is no longer executing and waits that the heir context
     242stopped execution before it restores the heir context and resumes execution of
     243the heir task.  So there is one point in time in which a processor is without a
     244task.  This is essential to avoid cyclic dependencies in case multiple tasks
     245migrate at once.  Otherwise some supervising entity is necessary to prevent
     246life-locks.  Such a global supervisor would lead to scalability problems so
     247this approach is not used.  Currently the thread dispatch is performed with
     248interrupts disabled.  So in case the heir task is currently executing on
     249another processor then this prolongs the time of disabled interrupts since one
     250processor has to wait for another processor to make progress.
     251
     252It is difficult to avoid this issue with the interrupt latency since interrupts
     253normally store the context of the interrupted task on its stack.  In case a
     254task is marked as not executing we must not use its task stack to store such an
     255interrupt context.  We cannot use the heir stack before it stopped execution on
     256another processor.  So if we enable interrupts during this transition we have
     257to provide an alternative task independent stack for this time frame.  This
     258issue needs further investigation.
     259
    214260@subsection Critical Section Techniques and SMP
    215261
Note: See TracChangeset for help on using the changeset viewer.