In comp.os.linux.misc Chris Carlen <crcarleRemoveThis@bogussandia.gov> wrote: > or RAID5? > > Any other ideas to achieve an instantaneously responsive system? > > Someone suggested putting a 2GB RAM disk in the extra RAM, and running a > background job once the system booted to copy most frequently used apps ramdisk is indeed the way to go if you want real performance. 2 decades ago it worked great, no reason why it shouldn't still do so. Copy the needed files to ramdisk at startup time so that by the time you log in they are already there and you won't see load times. Still won't be "instant" since you still need to instantiate the apps, but it should be about as good as would be possible. Stan -- Stan Bischof ("stan" at the below domain) www.worldbadminton.com

Chris Carlen <crcarleRemoveThis@BOGUSsandia.gov> writes: >Goal is to maximize desktop application loading performance. I want the >new machine to respond instantly to any application loading of the type >most commonly used in my case, such as Mozilla/Firefox, Acrobat, and >OpenOffice. > >If I use RAID0, it might offer the best performance, since much of >application load-to-launch delay I suppose comes from HD reading. But >RAID0 of course makes me twice as vulnerable to HD failure. You could use RAID0 for /usr (covering most of the binaries, libraries, and other data loaded by these applications), and RAID1 for the rest. If a disk dies, you could restore /usr from backup and the rest from the remaining disk; or just reinstall the system, and reuse configuration data from /etc. Note that RAID1 and RAID5 are no substitute for keeping a backup. >Thus, RAID5 >might be a compromise, but is getting a bit costly and noisy for a >desktop. Haven't decided yet to use Linux software RAID or use the >ICH9R hw RAID capabilities, though it seems like that might not work >with Linux. If you only use RAID0 and RAID1, you can just as well use only the software RAID. Then you can still access the data if the motherboard dies. >However, for about the same cost, I could put 4GB RAM on the machine >instead of a second or third HD. This would allow Linux to keep huge >amounts of data cached, so might make successive application launches >instantaneous after the first time, basically for the rest of the day >after booting. > >I have no need for more than 2GB RAM for running apps, and probably >actually don't need more than 1GB. In that case, you probably don't need 4GB to experience the caching effect. >Any other ideas to achieve an instantaneously responsive system? As others have mentioned, start up these applications when you start the system. Alternatively, when you start the system, cat all the files that these applications access so they get cached. You can find these files out by starting the systems with all the applications you are interested in, then do: cat /proc/*/maps|sed 's#[^/]*##'|sort -u Note that this will load quite a bit of stuff that is not used during application execution, but it is usually still quite a bit faster than executing the applications, which demand-pages the needed parts of these files. As long as you have enough RAM, the useless stuff won't be a problem and will eventually be dropped. >Someone suggested putting a 2GB RAM disk in the extra RAM, and running a >background job once the system booted to copy most frequently used apps >there. Then have the path set up to have the RAMdisk at the beginning >so as the apps appear in the RAM, they will load from there. But before >they are loaded in the RAMdisk, they will still load from the HD. I guess you will see a race condition there: as soon as you start copying the binary to the RAM disk, the path setup will try to execute it, even if it's not yet completely there. Also, how does the application binary know to access the application data on the RAM disk? Others have claimed that the RAM disk data will be copied again on execution, but I believe that the Linux kernel is smart enough to avoid that, and will map the page directly from the RAM disk into the process as long as the page is accessed read-only. So essentially the RAM disk solution will have a similar effect to the cat-warmed cache solution I suggested, but with the following differences: - The RAM disk approach needs path setups, the cat-warmed cache doesn't. - The RAM disk approach has a race condition (unless you work around that), the cat-warmed cache doesn't. - The RAM disk will keep the useless parts of the files in RAM all the time, the cat approach won't. - If you need lots of RAM for other purposes, the RAM disk will not free RAM, whereas the cat-warmed cache will drop pages to make room. Depending on your preferences, you may consider this an advantage for the RAM disk or the cache. Another alternative might be to use one of the suspend/hibernate features; AFAIK at least one of them loads the stuff eagerly into RAM (which is what you want). I don't have experience with that, though. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html