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.
-- 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
