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 <[EMAIL PROTECTED]> _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"