Comparing Linux and Minix [LWN.net]

Comparing Linux and Minix

Posted Feb 5, 2007 21:30 UTC (Mon) by davem (subscriber, #4154)
Parent article: Comparing Linux and Minix

To be honest, for me Tanenbaum's talk was the biggest disappointment
of LCA2007.

He's been arguing the same thing for 15+ years, and ignoring the same
critical issues during that entire time period.

The only thing new we got in his LCA2007 talk were some smoke-and-mirrors
benchmarks that nobody can reproduce because he didn't provide enough
details for anyone to even try to run them independantly.

When a computer scientist tells you X is faster than Y, you would
expect some kind of precise recipe by which you could independantly
reproduce the results. Right?

(Log in to post comments)

Comparing Linux and Minix

Posted Feb 5, 2007 21:55 UTC (Mon) by tjc (subscriber, #137) [Link]

The only thing new we got in his LCA2007 talk were some smoke-and-mirrors benchmarks that nobody can reproduce because he didn't provide enough details for anyone to even try to run them independantly.
When a computer scientist tells you X is faster than Y, you would expect some kind of precise recipe by which you could independantly reproduce the results. Right?

See the section "Papers about MINIX 3" on the MINIX 3 website.

http://www.minix3.org/doc/

Methodology used

Posted Feb 6, 2007 11:46 UTC (Tue) by pjm (subscriber, #2080) [Link]

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).

Methodology used

Posted Feb 6, 2007 15:40 UTC (Tue) by tjc (subscriber, #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 the
universe (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
space and incur no context switch overhead.

This is, of course, a standard memory for speed trade-off. Tridge (of
Samba fame) once described to me a case on some system where he tweaked
a kernel and libc in this way and saw a significant performance improvement
(some Fujitsu hardware?).

(Of course it's possible that the effect would be less dramatic on x86
hardware running Linux --- but it's still an option to consider. If we
did it then I imagine it would be a bit like the VDSO mapping the kernel
is already doing for the latest TLS support. The system call would still
exist for legacy support ... but newer libc updates would check for and
use the extra data area for return such data. (The time of day and
perhaps some other dynamic system-wide information would all be stored
in one or two read-only pages which would be aliased into every user
address space be default ... while process-state info would be mapped
into private pages. Obviously some accomodation for the virtualization
models would have to be made --- so each virtual kernel would have it's
own pages to map into process).

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.)