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