[Click] Multithreaded question

Eddie Kohler kohler at cs.ucla.edu
Sat Feb 27 20:23:51 EST 2010


Hi Raja,

For some discussion on the "best" way to assign tasks to threads, see the 
paper by Chen and Morris, "Flexible COntrol of Parallelism...".

As for your 1-4, the thing about queues is that they are in *both* a push 
region *and* a pull region; that is their entire point.  Queues are passive 
elements and do not beling to threads themselves.  So your 2-4 options don't 
really make sense.

FWIW at Intel's Routebricks project we have found it valuable to ensure that 
only one core touches a packet on its entire path through the router. 
Parallelism is achieved by having separable paths.

As for bursty behavior, hard to know there what you mean either.  Were you 
using StaticThreadSched?  BalancedThreadSched?  If you didn't use either, then 
in your multithreaded program only one thread was doing all the work.

Eddie


rajamhayek at yahoo.com wrote:
> Hi Eddie,
> 
> I am not sure how the threading/stride scheduling work together.  I have 
> included a sample image, extracted from a Master's thesis, that describe 
> the single threaded execution.  In this picture, the active elements 
> (A1, A2, and A3) are scheduled to run in sequence.  When they do run, 
> they call synchronously the elements they are connected to until a queue 
> (passive element) is reached.  This decomposes the execution into 
> push/pull regions. Now we want to move this to multithreaded execution, 
> what is the best way of adding elements to threads:
> 
> 1- Only the active elements run on threads.
> 2- The full regions are assigned to threads and the queues remain in the 
> main thread.
> 3- The full regions are assigned to threads and the queues are in the 
> push region.
> 4- The full regions are assigned to threads and the queues are in the 
> pull regions.
> 
> So far with our application, assigning only active elements to threads, 
> we are getting an unwanted bursty behavior of packet.  In single 
> threaded, the bursty behavior disappears but we do not reach the 
> required throughput.  I appreciate any pointers that can help us resolve 
> this problem.
> 
> Thank you,
> Raja
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 


More information about the click mailing list