[PATCH 8/8] score: Add scheduler assignments for SMP

[Gedare Bloom]

On Fri, Apr 11, 2014 at 2:03 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 04/11/2014 07:27 PM, Gedare Bloom wrote:
>>
>> [...]
>>>
>>> diff --git a/doc/user/conf.t b/doc/user/conf.t
>>> index 9b093f8..e3c3f24 100644
>>> --- a/doc/user/conf.t
>>> +++ b/doc/user/conf.t
>>> @@ -3792,6 +3792,99 @@ guidance.  For guidance on the configuration
>>> macros, please examine
>>>   Deterministic Priority Scheduler.
>>>
>>>   @c
>>> + at c === Configuring Partitioned/Clustered Schedulers ===
>>> + at c
>>> + at subsection Configuring Partitioned/Clustered Schedulers
>>> +
>>> +Partitioned/clustered scheduling helps to control the worst-case
>>> latencies in
>>> +the system.  The goal is to reduce the amount of shared state in the
>>> system and
>>> +thus prevention of lock contention.  Modern multi-processor systems tend
>>> to
>>> +have several layers of data and instruction caches.  With
>>> partitioned/clustered
>>> +scheduling it is possible to honor the cache topology of a system and
>>> thus
>>> +avoid expensive cache synchronization traffic.
>>> +
>>> +The schedulers in an SMP system are statically configured.  First the
>>> +application must select which scheduling algorithms are available with
>>> the
>>> +following defines
>>> +
>>> + at itemize @bullet
>>> + at item @code{CONFIGURE_SCHEDULER_PRIORITY_SMP},
>>> + at item @code{CONFIGURE_SCHEDULER_SIMPLE_SMP}, and
>>> + at item @code{CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP}.
>>> + at end itemize
>>> +
>>> +After these definitions the configuration file must
>>> + at code{#include <rtems/scheduler.h>} to have access to scheduler specific
>>> +configuration macros.  Each scheduler needs a context to store state
>>> +information at run-time.  To provide a context for each scheduler is the
>>> next
>>> +step.  Use the following macros to create scheduler contexts
>>> +
>>> + at itemize @bullet
>>> + at item @code{RTEMS_SCHEDULER_CONTEXT_PRIORITY_SMP},
>>> + at item @code{RTEMS_SCHEDULER_CONTEXT_SIMPLE_SMP}, and
>>> + at item @code{RTEMS_SCHEDULER_CONTEXT_PRIORITY_AFFINITY_SMP}.
>>> + at end itemize
>>> +
>>> +The schedulers are registered in the system via the scheduler table.  To
>>> create
>>> +the scheduler table define @code{CONFIGURE_SCHEDULER_CONTROLS} to a list
>>> of the
>>> +following scheduler control initializers
>>> +
>>> + at itemize @bullet
>>> + at item @code{RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP},
>>> + at item @code{RTEMS_SCHEDULER_CONTROL_SIMPLE_SMP}, and
>>> + at item @code{RTEMS_SCHEDULER_CONTROL_PRIORITY_AFFINITY_SMP}.
>>> + at end itemize
>>> +
>>> +The last step is to define which processor uses which scheduler.  For
>>> this
>>> +purpose a scheduler assignment table must be defined.  The entry count
>>> of this
>>> +table must be equal to the configured maximum processors
>>> +(@code{CONFIGURE_SMP_MAXIMUM_PROCESSORS}).  A processor assignment to a
>>> +scheduler can be optional or mandatory.  The boot processor must have a
>>> +scheduler assigned.  In case the system needs more mandatory processors
>>> than
>>> +available then a fatal run-time error will occur.  To specify the
>>> scheduler
>>> +assignments define @code{CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS} to a list
>>> of
>>> + at code{RTEMS_SCHEDULER_ASSIGN} macros.
>>> +
>>> +The following example shows a partitioned scheduler configuration for
>>> two
>>> +processors.  Each processor is owned by a Deterministic Priority
>>> scheduler
>>> +capable to manage 256 priority levels.  The scheduler with index zero
>>> has the
>>> +name @code{"BLUE"}.  The scheduler with index one has the name
>>> @code{"WOOD"}.
>>> +The scheduler assignments are mandatory, so the system must have at
>>> least two
>>> +processors, otherwise a fatal run-time error will occur during system
>>> startup.
>>> +
>>> + at example
>>> + at group
>>> +#define CONFIGURE_SMP_APPLICATION
>>> +
>>> +#define CONFIGURE_SMP_MAXIMUM_PROCESSORS 2
>>> +
>>> +#define CONFIGURE_MAXIMUM_PRIORITY 255
>>> +
>>> +#define CONFIGURE_SCHEDULER_PRIORITY_SMP
>>> +
>>> +#include <rtems/scheduler.h>
>>> +
>>> +RTEMS_SCHEDULER_CONTEXT_PRIORITY_SMP(a, CONFIGURE_MAXIMUM_PRIORITY + 1);
>>> +
>>> +RTEMS_SCHEDULER_CONTEXT_PRIORITY_SMP(b, CONFIGURE_MAXIMUM_PRIORITY + 1);
>>> +
>>> +#define CONFIGURE_SCHEDULER_CONTROLS \
>>> +  RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \
>>> +    a, \
>>> +    rtems_build_name('B', 'L', 'U', 'E') \
>>> +  ), \
>>> +  RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \
>>> +    b, \
>>> +    rtems_build_name('W', 'O', 'O', 'D') \
>>> +  )
>>> +
>>> +#define CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS \
>>> +  RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY),
>>> \
>>> +  RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY)
>>> + at end group
>>> + at end example
>>> +
>>
>> Make it more clear in the documentation that the index passed to
>> RTEMS_SCHEDULER_ASSIGN identifies the scheduler based on the order
>> they are defined in the CONFIGURE_SCHEDULER_CONTROLS, and that the
>> order of the assignments implies the processor being assigned.
>>
>> -Gedare
>
>
> Ok.
I'm having some concerns that this way of configuring a system may be
overly complex, and once we "commit" to it we will be stuck with the
complexity of this approach. Please consider some ways to simplify the
user-level interface for scheduler configuration.

I suppose this is part and parcel of RTEMS configuration in general,
but the amount of extra logic required here beyond the usual approach
in RTEMS of setting maximum constraints has me troubled.

-Gedare

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>