[Click] Click scheduling change

[Brecht Vermeulen]

Hi Eddie,

groovy change !

Other advantages I see (or I hope to see :-) ):
- the kernel won't run out of kernel threads if swapping a lot (e.g. if 
benchmarking hotconfig :-) )
- no zomby click threads lying around in the kernel after swapping

It's a pity I haven't the time for the moment for testing this out.

regards,
Brecht


Eddie Kohler wrote:

> Hi all,
> 
> I've just checked in a refactoring of the way that Click does scheduling.
> 
> Previously, each Click thread was "owned" by a particular Router object.
> When you changed Routers, the old Router's threads were killed, and new
> threads started up.  This happened even on hotswap.
> 
> Now, Click threads are "owned" by a persistent object, the Master.  When
> kernel Click starts up, it creates N threads, which remain around until you
> rmmod the module.  When you change Routers, you change the tasks active in
> the Master, but not the kernel threads themselves.
> 
> This has a couple benefits.  Hotswaps should be faster and more reliable.
> User-level programs can run several routers concurrently by giving them the
> same Master.  Also, some kinds of Click configurations will take less CPU
> time than they formerly did, because the threads put themselves to sleep as
> appropriate.
> 
> There may be bugs of course.  Please write in if you see weird behavior.
> Eddie
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click