This shows you the differences between two versions of the page.
minixperformance [2014/11/11 14:52] |
minixperformance [2014/11/11 14:52] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | This page is to collect observations and experiments related to performance of minix. | ||
+ | |||
+ | ====== Starting point ====== | ||
+ | |||
+ | There are countless ways to talk about performance, so let's start with one simple case that is both relevant for our daily usage and displays terrible performance: gcc and clang on minix. | ||
+ | |||
+ | ====== Basic Observations ====== | ||
+ | |||
+ | * Clang is significantly slower than gcc on minix, and it's supposed to be faster. | ||
+ | * There is high idle time when gcc and clang are executing, suggesting high i/o wait time | ||
+ | |||
+ | ====== Experiments ====== | ||
+ | |||
+ | (Timing measurements to be done.) | ||
+ | |||
+ | * Run with huge primary cache: no more idle time. clang is still significantly slower than gcc though, and gcc still isn't very fast. | ||
+ | * Run with /usr/tmp, /tmp and /usr/src on ramdisks: almost no idle time any more. | ||
+ | * Marking unreferenced blocks as clean if they're dirty: happens but doesn't help much in real time. | ||
+ | * Defer evicting dirty blocks from the cache, prefering a clean block even if it's older in order to batch write operations: helps with reducing flushall() calls but not much in real time. | ||