Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Processors/DSPs
 
 
Processors/DSPs  

Improving multi-core system power/performance trade-offs

Posted: 03 Jul 2012     Print Version  Bookmark and Share

Keywords:embedded software design  symmetrical multi-processing  parallelism 

This example was selected because this kind of scheduling is the most common in today's commercially available RTOSes. Such an approach ensures that the most important thread (highest priority) always gets the first opportunity to run.

Any low priority preemptable thread can be kicked out only by a thread of a higher priority. Therefore, an indirect guarantee of real-time operation is available for critical threads. The same priority threads are executed in a round-robin fashion. A simple multi-core extension of this model simply takes the highest priority 'n' (0 < n < M-1) threads and dispatches them to any of the 'n' available free cores.

Parent-child programming model
From the perspective of using as much legacy code as possible, the easiest path to multi-core development is via TLP under a parent-child programming model. Under this paradigm application code remains agnostic from parallel programming constructs. The parent-child model does not impact the deadline requirements as long as it can keep TLP under limits.

For instance, a legacy application thread (parent) performing video frame decoding can speed up its execution using TLP by distributing frames among its child threads. These child threads will then execute in parallel on multiple available cores potentially increasing the performance of the system.

There is very little requirement of a code change. A parent needs to span and then wait for all children to finish. If the thread creation (fork) and wait time (join) are small as compared to the thread workload, the deadline requirement of original thread will easily be fulfilled. Fork and join services are usually wrappers around other standard RTOS interfaces explained next.

Fork-join services
A common way for an RTOS to support POSIX-style fork service is to provide a wrapper function around thread creation API with the addition of setting up a mailbox or event associated with this child thread. Information of an event (mail box) is added to thread data (possibly in thread control block). In case of a join call, the RTOS checks the status of event/mailbox to determine if the child has completed execution. This simplistic arrangement results in TLP synchronisation overhead since it depends on components of RTOS other than software contexts.

Figure 1: Illustration of proposed fork-join with parent-child model.

Techniques to reduce RTOS overhead
The proposed scheme in figure 1 shows the nodes that represent a thread (either parent or child) while the branches indicate the fork-join operations. Each node is labelled by the priority level (except the last node labelled as E to indicate the end state).


 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page



Comment on "Improving multi-core system power/pe..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top