Re: libcaps thread testing code committed

[David Leimbach <leimy2k@xxxxxxx>]

Just got back from yet another business trip so I am behind on my
DragonFly Email.

On Dec 6, 2003, at 10:49 PM, Matthew Dillon wrote:

>     Thread testing code has been committed for libcaps.  Note that the 
> FP
>     regs are not saved and restored yet (though there is assembly to 
> do it
>     present).  I did some preliminary switch overhead tests with fp 
> save and
>     restore and without.  2 million lwkt_swich() calls execute in 0.15
>     second while the same test which also saves and restore FP regs ran
>     in 0.45 seconds.  So it's the difference between 
> 75ns/context-switch
>     and 225ns/context-switch (on an AMD-64).

Awesome :).  I guess I can get started with some examples soon then.  
Problem
is I've been handed a flurry of work to complete in the next two weeks 
before my
Christmas vacation begins and I won't have a dragonfly PC around to 
work on
[unless it works on PowerPC :)].

>     Still TODO:
>
> 	System call messaging	(Galen is working on this)

Might have to wait for this anyway...


> 	Libcr sync from libc, and libcr tie-ins for mp_lock
> 	(e.g. using get_mplock() and rel_mplock())

Haven't had coffee yet so this looks like Sanskrit... moving on.

> 	Other lock or mutex functionality to support the new libcr.
>
> 	Kernel asynchronous syscall messaging support.

So its all synchronous at the moment?  Does this mean there are no
queues or that, as in cooking, all the prep is done and we just need the
proper recipe to combine the ingredients to bake up some asynchronous
support.

>     This commit 'proves out' the upcall API fairly well.  I was able to
>     implement all the infrastructure necessary to support user 
> threading,
>     including IPI's between virtual cpus (rfork'd processes), without
>     having to drop into the kernel to performing a thread switch.

Groovy.

> 						-Matt