Comparing Linux and Minix [LWN.net]

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 (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 (guest, #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.)

gettimeofday() -- user-space vs. system call

Posted Aug 23, 2010 13:09 UTC (Mon) by Blaisorblade (guest, #25465) [Link]

The mechanism you describe is only valid for i386.
That mechanism is used on x86_64, for one - see arch/x86/kernel/vsyscall_64.c:vgettimeofday and/or arch/x86/vdso/vclock_gettime.c (two different reimplementations of the same concept).

However, the existing implementation for x86_64 requires libc support, and no implementation of this for x86_32 exists. Dunno why.
The only difference I seem to see is that on i386 there is no support for int 0x80 calls, so probably libc uses syscall/sysenter directly.

Comparing Linux and Minix

Posted Aug 23, 2010 12:26 UTC (Mon) by Blaisorblade (guest, #25465) [Link]

> 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?

Before being a computer scientist, I thought so as well. In practice, while it is obviously desirable, it is also never true.
The very first time I asked my professor, I learned that in most CS communities you are NOT expected to publish a verifiable implementation, because that would rule out closed-source/industrial research.

Quite often, you have to re-implement every described algorithm for a comparison. And in many fields (say pattern recognition, of voice/images/objects/whatever) there's a lot of algorithmic/heuristic tuning to do - results of such tuning are unpublished implementation tricks, so you can't reproduce anything. I know it for a fact - a professor I had for a course told us he did so in his most successful publication (I can write that because you can't associate my name with his).
Having said that, publishing source code of course helps, but it's rarely required. Otherwise, I would guess, Microsoft Research couldn't publish so many papers to a top-level conference like ACM SIGGRAPH (but note that Microsoft Research also works on Open Source software, like the Glasgow Haskell Compiler; just no Free Software, to my knowledge).