| |||||||||||
Methodology usedMethodology usedPosted Feb 6, 2007 11:46 UTC (Tue) by pjm (subscriber, #2080)In reply to: Comparing Linux and Minix by tjc Parent article: Comparing Linux and Minix
Specifically, "A Lightweight Method for Building Reliable Operating Systems Despite Unreliable Device Drivers" compares MINIX 2 with MINIX 3, and finds syscall slowdowns of 7% to 18% (or 22% for getpid and presumably other very simple syscalls; gettimeofday is the most common very simple syscall I can think of off the top of my head). I don't know whether MINIX 3 contains any significant performance improvements that could reasonably be applied to MINIX 2 as well, but at least the comparison is against a realistic monolithic kernel (presumably not using message passing).
(Log in to post comments)
Methodology used Posted Feb 6, 2007 15:40 UTC (Tue) by tjc (guest, #137) [Link] I don't know whether MINIX 3 contains any significant performance improvements that could reasonably be applied to MINIX 2 as well, [snip]As far as I know neither MINIX 2 or MINIX 3 contain anything at all in the way of perfomance enhancements. The simple algorithms are used for everything so that they are easy to understand. ... but at least the comparison is against a realistic monolithic kernel (presumably not using message passing).MINIX 2 uses a microkernel - and message passing - as well. I'd have to dig out my MINIX 2 book to be sure, but IIRC MINIX 2 had most of the OS running as a single user-mode process, and the drivers in the kernel, whereas MINIX 3 has most of the OS and all the drivers (except the clock) partitioned into seperate user-mode processes. So MINIX 2 is quite slow, and MINIX 3 is a bit slower than that.
gettimeofday() -- user-space vs. system call Posted Feb 6, 2007 20:06 UTC (Tue) by AnswerGuy (subscriber, #1256) [Link] While gettimeofday() should be one of the simplest system calls in theuniverse (and uname() should be another) ... it's even better if you have a kernel that implemeents these as pre-initialized data mappings into every process' address space.
Then the libc can just fetch the relevant data from its own address
This is, of course, a standard memory for speed trade-off. Tridge (of
(Of course it's possible that the effect would be less dramatic on x86
JimD
gettimeofday() -- user-space vs. system call Posted Feb 7, 2007 9:26 UTC (Wed) by ekj (subscriber, #1524) [Link] The balance tends to shift over time too.The amount of memory available increases a lot more than the available syscalls do. In other words, putting the data that gettimeofday() needs into the address-space of every process costs just as many bytes now as it always did (well, modulus avg number of processess on a box), but the available memory increases exponentially. Lots of stuff may make sense on a 16GB machine which doesn't make sense on a 4MB machine. If you do enough such trickery that you'd have wasted half the RAM of the 4MB machine you'll have wasted 0.01% of the memory of the large machine. If you assume the large machine has 10 times as many processes, you've still only wasted 0.1% of the available memory. This is even more true for space/performance tradeoffs that are internal to the kernel only. Back when Linux was new, wasting 1MB to double in-kernel performance would've been ridicolous. Today it's equally obvious that it'd be a huge win in most scenarios. Gets complicated though, because larger structures tend to hurt cache-hit ratio, and main-memory is *SLOW* compared to on-die-cache.
gettimeofday() -- user-space vs. system call Posted Feb 7, 2007 16:53 UTC (Wed) by nix (subscriber, #2304) [Link] You don't need any libc support for this (other than the existing vsyscall support). The code on the vsyscall page which normally runs SYSENTER could spot that the syscall being invoked is gettimeofday() and copy out the appropriate value from elsewhere in the vsyscall page without ever transitioning to kernel mode. (A patch of this nature was discussed a few years ago, but I'm not sure if any code resulted.)
|
|||||||||||