[Click] RFC: "threading" branch on Github kohler/click

[Eddie Kohler]

Hi Beyers,

On 6/1/11 5:52 PM, Beyers Cronje wrote:
> Hi Eddie,
>
> This is awesome, great stuff! I'm working against a deadline on a project this
> week, so unfortunately I'll probably only get to testing this some time next
> week and report back to you how my own testing went.

No problem!

> Out of interest, how is a timer allocated to a thread when the timer is in an
> element that is connected to two threads? As an example if you have a Queue
> type element that makes use of a timer, obviously this element sits on both
> pull and pull threads. To which thread will it be allocated?

Currently the allocation strategy is SUPER simple.  A Timer is associated with 
thread 0, unless there is a StaticThreadSched for its element, in which case 
it is associated with that thread.  One can imagine more complex policies, 
including looking upstream or downstream for related elements, but this is a 
start.

Eddie

>
> Beyers
>
> On Thu, Jun 2, 2011 at 1:30 AM, Eddie Kohler <kohler at cs.ucla.edu
> <mailto:kohler at cs.ucla.edu>> wrote:
>
>     Dear Click power users,
>
>     Please take a look at the Github "threading" branch, and test it out.
>       This branch is meant to improve Click's multicore scheduling.  It
>     introduces per-thread sets of timers (and, at userlevel, selected file
>     descriptors), which should limit lock contention on these important data
>     structures. Several other cleanups are included.  A fair amount of work
>     was done to keep performance high on a trivial test case, but I'm not sure
>     what has happened on other test cases.  Any feedback would be appreciated.
>
>     Eddie
>
>