Fairness of comparing OSs that don't support paging [LWN.net]

Fairness of comparing OSs that don't support paging

Posted Feb 6, 2007 12:57 UTC (Tue) by pjm (subscriber, #2080)
In reply to: Comparing Linux and Minix by iabervon
Parent article: Comparing Linux and Minix

I haven't thought long about it, but I don't think it's true that choosing which bits are pageable is "trickier to implement with [microkernels] than the alternative": one can get it right just by having code have the same pageability as it would have in a monolithic kernel.

(One may well be able to do better than that in a microkernel at the cost of some trickiness, but that freedom acts, if anything, in the favour of microkernels if one were to compare between systems that support paging.)

Paging is one of the operations that should be more costly if I/O drivers are in separate processes. So timing tests that involve paging would show more absolute difference than tests that don't involve paging, but OTOH relative difference would actually be less if the paging is of the thrashing kind (i.e. with CPU idle a lot of the time).

If we want to know the performance effect of applying microkernel ideas to typical Linux-based systems, then the omission of paging from the comparisons is of less concern to me than the omission of a windowing system.

(Log in to post comments)

Fairness of comparing OSs that don't support paging

Posted Feb 6, 2007 15:56 UTC (Tue) by tjc (guest, #137) [Link]

... the omission of a windowing system.

X has been ported to MINIX, as our editor mentioned in the article.

Fairness of comparing OSs that don't support paging

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

I meant the omission of timings for windowing system operations (at least in the article I cited; I can't find slides for AST's LCA talk).

This omission is understandable in that the windowing system isn't part of the kernel in either MINIX or Linux, and the decision to reduce its access to hardware is more or less independent of [other] microkernel/monolithic decisions technically; though a person considering applying these principles to the kernel would naturally be interested in applying the same principles to X.

Fairness of comparing OSs that don't support paging

Posted Feb 6, 2007 18:53 UTC (Tue) by khim (guest, #9252) [Link]

In monolithic kernel pageability depends on type of memory (you can just throw away code pages, you need to swap out data pages), on type of memory (you can swap from memory to memory in NUMA system!), on type of access (linux uses not just dirty/clear flag but a lot of heuristics to decide what to swap out out and what to keep), etc. It's easy to have this data in "flat" kernel: it's all easily accessible, there are no borders. With microkernel it's much harder: either you imlement "naive" paging (and it does not work very well) or you somehow make systems interdependent - and then what is the point of microkernel ?

Microkernel simply makes a lot of optimizations much harder. It's not clear if it's possible to reach 90% of linux speed with microkernel approach... MINIX does not do this - that's for sure...

Fairness of comparing OSs that don't support paging

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

Do the difficulties khim mentions relate to whether drivers are in userspace, or only on other whether process and paging implementations are in userspace?

AST makes the point that drivers are typically noticeably buggier than the rest of a kernel (an observation previously made by others (Linus?) about Linux specifically), and so reliability concerns might make one move poorer quality drivers to userspace even if higher-reliability code (such as paging and process stuff) stays in kernel space.