On Fri, Sep 4, 2015 at 2:35 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 03/09/15 16:59, Gedare Bloom wrote:
>>
>> On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de> wrote:
>>>
>>> >---
>>> > doc/user/smp.t | 38 ++++++++++++++++++++++++++++++++++++++
>>> > 1 file changed, 38 insertions(+)
>>> >
>>> >diff --git a/doc/user/smp.t b/doc/user/smp.t
>>> >index 1b4849a..ba700e0 100644
>>> >--- a/doc/user/smp.t
>>> >+++ b/doc/user/smp.t
>>> >@@ -147,6 +147,44 @@ 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.
>>> >
>>> >+@subsection Clustered/Partitioned Scheduling
>>> >+
>>> >+We have clustered scheduling in case the set of processors of a system
>>> > is
>>> >+partitioned into non-empty pairwise-disjoint subsets. These subsets are
>>> > called
>>> >+clusters. Clusters with a cardinality of one are partitions. Each
>>> > cluster is
>>> >+owned by exactly one scheduler instance.
>>> >+
>>> >+Clustered/partitioned scheduling helps to control the worst-case
>>> > latencies in
>>> >+the system, see @cite{Brandenburg, Björn B.: Scheduling and Locking in
>>> >+Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
>>> >+@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}. 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 clustered/partitioned scheduling it is
>>> > possible to
>>> >+honour the cache topology of a system and thus avoid expensive cache
>>> >+synchronization traffic. It is easy to implement. The problem is to
>>> > provide
>>> >+synchronization primitives for inter-partition synchronization. In
>>> > RTEMS there
>>> >+are currently three means available
>>> >+
>>> >+@itemize @bullet
>>> >+@item events,
>>> >+@item message queues, and
>>> >+@item semaphores using the @ref{Semaphore Manager Multiprocessor
>>> > Resource
>>> >+Sharing Protocol} (MrsP).
>>> >+@end itemize
>>> >+
>>> >+The clustered/partitioned scheduling approach enables separation of
>>> > functions
>>> >+with real-time requirements and functions that profit from fairness and
>>> > high
>>> >+throughput provided the scheduler instances are fully decoupled and
>>> > adequate
>>> >+intra-partition synchronization primitives are used. This is work in
>>> > progress.
>>
>> inter-partition? inter-partition doesn't make sense. Also, to be
>> general, it should really be inter-cluster, which goes for the above
>> use of "inter-partition" as well. Because of the use of partition in
>> Partitioned Scheduling, we have to be careful about the use of
>> partition in other places related to SMP scheduling, unfortunately.
>>
>
> Would it be better to replace "clustered/partitioned scheduling" with
> "clustered scheduling" throughout the manual and just mention that
> partitions are clusters with exactly one processor? So we have
> "inter-cluster synchronization" for synchronization that involves more than
> more cluster and "intra-cluster synchronization" for synchronization that
> involves exactly one cluster.
>
Yes.
> --
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
