Assembly Syscall Question

[Matthew Dillon]

:You need 8K for this, minimally: 4K that's RO user/RW kernel and
:4K that's RW user/RW kernel.  You can use it for things like zero
:system call getpid/getuid/etc..
:
:It's also worth a page doubly mapped, with the second mapping with
:the PG_G bit set on it (to make it RO visible to user space at the
:sampe place in all programs) to hold the timecounter information;
:the current timecounter implementation, with a scad of structures,
:is both wasteful and unnecessary, given that pointer assigns are
:atomic, so you can implement with only two, which only take a small
:part of the page.  Doing this, you can use a pointer reference and
:a structure assign, and a compare-pointer-afterwards to make a zero
:system call gettimeofday() and other calls (consider the benefits
:to Apache, SQID, and other programs that have hard "logging with
:timestamp" requirements).
:
:I've also been toying with the idea of putting environp ** in a COW
:page, and dealing with changes as a "fixup" operation in the fault
:handler (really, environp needs to die, to make way for logical name
:tables; it persists because POSIX and SuS demand that it persist).
:
:So, Matt... how does the modified message based system call
:interface fare in a before-and-after with "lmbench"?  8-) 8-).
:
:-- Terry

    In regards to using shared memory to optimize certain things, like
    the time functions... I believe it will be possible to do this in a
    portable fashion by going through the emulation layer (which is really
    misnamed... basically the syscall interface layer which will run in
    userspace but whos code will be managed by the kernel).  We don't want
    the user program having direct knowledge of memory mapped gizmos, but
    it's perfectly acceptable for the emulation layer to have this knowledge,
    because the emulation layer will know how to fall back if the gizmo
    isn't where it's supposed to be (i.e. you boot an older kernel with a
    newer userland).

    The messaging code works fairly well so far performance-wise.   My
    original getuid() vs messaging getuid() test on a DELL 2550 (SMP build)
    comes out:

    getuid() 0.974s 1088300 loops =  0.895uS/loop
    getuid() 0.937s 1047500 loops =  0.894uS/loop
    getuid() 0.971s 1084700 loops =  0.895uS/loop
    getuid_msg() 1.029s 935400 loops =  1.100uS/loop
    getuid_msg() 0.970s 881600 loops =  1.100uS/loop
    getuid_msg() 0.963s 876600 loops =  1.099uS/loop

    About 200ns slower, and I haven't really tried to optimize any of it
    yet (and I'm not going to worry about it until a lot more work has
    been accomplished anyway).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>