| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 8:43 UTC (Fri) by kju (subscriber, #61936)In reply to: The case for the /usr merge by AndreE Parent article: The case for the /usr merge
building them into a ramdisk, which is still much much faster than an SSDYou really believe this? It is likely much slower because the ramdisk needs to be completely loaded into RAM (and maybe unpacked) before it can be used. If you only use part of the content (selected binaries) you are loading lots of unnecessary stuff and in the end this is much slower than loading only the needed files directly from an SSD.
(Log in to post comments)
The case for the /usr merge Posted Jan 27, 2012 9:54 UTC (Fri) by ebiederm (subscriber, #35028) [Link]
Last I benchmarked it I could load a full distro image compressed to about 800MiB in about 8 seconds over GigE. Almost enough time to notice I was waiting and then everything ran out of RAM.
Anything less than a full distro looks like too little data to even care about the performance on modern hardware.
The case for the /usr merge Posted Jan 27, 2012 21:42 UTC (Fri) by AndreE (subscriber, #60148) [Link]
Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster
So what arbitrary measure should we use to benchmark our system rescue? The main point remains that "performance of loading binaries" is hardly a prime concern for system rescue situations.
The case for the /usr merge Posted Jan 27, 2012 22:06 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster
as long as you have enough ram to both hold the ramdisk _and_ the working set for all your applications.
|
|||||||||||||