libcaps thread testing code committed

David Leimbach leimy2k at mac.com
Mon Dec 8 05:53:20 PST 2003


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







More information about the Kernel mailing list