libcaps thread testing code committed
Matthew Dillon
dillon at apollo.backplane.com
Sat Dec 6 20:50:49 PST 2003
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).
So far my investigation into using a delayed-FP-save has been
unsuccessful. The only way to generate an FP exception on FP-use
is with a CR0 bit and needless to say this cannot be done from
userland. We can designate integer threads to avoid saving and
restoring FP regs in those threads, but otherwise I don't see any way
to avoid it.... remember, anything that adds a system call will add
about a microsecond to the switch code, so implementing anything
that requires a system call will wind up being slower then just
unconditionally saving and restoring the FP regs.
--
NOTE! There is a notion of a 'mp_lock' but we have not yet made the
libc tie-in's for it, so in fact my test code does some really bad
things by calling STDIO library functions and using the global errno
right now :-).
In order to play with this stuff you need a kernel with the USER_LDT
option compiled in.
This commit represents major progress in userland threading.
Still TODO:
System call messaging (Galen is working on this)
Libcr sync from libc, and libcr tie-ins for mp_lock
(e.g. using get_mplock() and rel_mplock())
Other lock or mutex functionality to support the new libcr.
Kernel asynchronous syscall messaging 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.
-Matt
More information about the Kernel
mailing list