Assembly Syscall Question

[Matthew Dillon]

    It's a toss up.   Linux's use of registers for syscall args is not 
    a panacea, because many system calls require more then just the basic
    call-used registers which means the linux userland code has to save
    and restore those registers on the stack anyway.  And we won't even
    mention syscalls that require more arguments then you have registers
    for.  Oops!

    I think the ultimate performance solution is to have some explicitly
    shared memory between kerneland and userland and store the arguments,
    error code, and return value there.  Being a fairly small package of
    memory multi-threading would not be an issue as each thread would have
    its own slot.

    Of course, FreeBSD has other problems as well.. if you look at our syscall
    entry and exit code it is simply *horrendous*  It goes through an
    indirect jump and it has to check carry for error returns to set the
    error code.  It is a real mess.

    What I am doing in DragonFly is reimplementing system calls as messages.
    It turns out that the overhead is not signifcantly greater (and I haven't
    even tried optimizing the code yet).  With the system call as a message
    the return code and error are stored in the message itself which means
    that there are *NO* no special cases and, at least for IA32, the kernel
    messaging interface has just three fixed arguments which fit easily
    in the call-used registers.  I've been able to get rid of proc->p_retval[],
    a considerable amount of unnecessary proc/thread pointer passing,
    and the mechanism is flexible enough to support both synchronous 
    and asynchronous operation as well as both single and multi-threaded
    operation using the same exact code.  Additionally, the mechanism can
    be extended to support chained system calls (i.e. issue several system
    calls at once), and transactional sequences.  Of course, I haven't 
    actually done all of this yet... I have the messaging infrastructure in
    place and I am working on asynchronizing I/O and timing system calls
    (e.g. sleep(), read(), write(), select(), etc..), which is going to take
    a lot of work, but once that is done the sky is the limit.

						-Matt

:On Fri, 2003-08-01 at 02:59, Terry Lambert wrote:
:> Personally, I like to look at the Linux register-based passing
:> mechanism in the same light that they look at the FreeBSD use
:> of the MMU hardware to assist VM, at the cost of increased
:> FreeBSD VM system complexity (i.e. they think our VM is too
:> convoluted, and we think their system calls are too convoluted).
:
:Maybe, but they also support a lot of MMU-less architectures, so it may
:have made things simpler for them to not depend on MMU. I wonder if NUMA
:had any bearing on that as well...
:
:-- 
:Shawn <drevil at warpcore.org>