DragonFly BSD
DragonFly kernel List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

libcaps thread testing code committed


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 6 Dec 2003 20:49:22 -0800 (PST)

    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




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]