Preload Drastically Boosts Linux Performance

Nemilar writes "Preload is a Linux daemon that stores commonly-used libraries and binaries in memory to speed up access times, similar to the Windows Vista SuperFetch function. This article examines Preload and gives some insight into how much performance is gained for its total resource cost, and discusses basic installation and configuration to get you started."

Re:But I thought Vista doing it = RAM hogging?

[bersl2]

You have the option not to run this sort of program. If it sucks, turn it off.

Also, Windows' VM system (IMNSHO) has always sucked and will continue to suck; predictive loading of entire bits of software has nothing to do with it.

Re:But I thought Vista doing it = RAM hogging?

[Anonymous Coward]

Presumably the linux implementation is better. Heck, just look at how disabling swap (or using a ramdisk for swap) dramatically improves performance in windows because of it's sucky virtual memory system if you don't believe me.

Re:What, what?

[Anonymous Coward]

SuperFetch was one of the first things that I had to disable in Vista. I had downloaded a linux distro (a large .iso file) using Firefox, and for the next two weeks, everytime I rebooted my computer I would have to listen to my hard drive chug away for the next 10 minutes while it loaded the file into memory. (The new resource monitor in Visa is nice -- that is what helped me track down the problem).

My computer is MUCH faster now that SuperFetch is disabled. Like night and day.

Re:What, what?

[ozmanjusri]

it's an old, but good idea.

The Amiga one of the same era was very good. You had a recoverable RAM disk, which functioned the same as a standard RAM disk, but would maintain its contents on restart. That meant reboots were lightning quick, and any data you stored in the RRAM disk was still there.

Shame we haven't got back to that level of functionality.

Difference with readahead?

[pieleric]

Currently I use readhead [fedoraproject.org] which, at boot time, basically uses a special linux syscall to tell the kernel to read some files ahead whenever it has nothing else better to read.

Does anyone knows the difference between the two projects? Does preload have a better algorithm for selecting the files to read? Does it also use this special syscall?

Re:What, what?

[pipatron]

Except when you were coding something that ran away in memory, corrupted the RAD (the name of the recoverable RAM disk), destroying everything you hadn't saved for an hour or so. :)

(The Amiga didn't have an MMU originally, and even when they got it, the OS didn't support memory protection due to the shared message passing)

Re:LiveCDs do this...

[The Mighty Buzzard]

Unless you're still coming from the Windows mindset where you're used to closing an application after every use of it, preload isn't of much use at all. If you never close an application, startup time is not an issue. The firefox window I'm posting this response from now has an uptime longer than any windows box with automatic updates turned on and is only clocking in at 118M/22M resident/shared. I could possibly see it being of some use if you actually open and close OO.o regularly (it's a slow, bloated beast even by Microsoft standards) but that's an argument against OO.o not an argument in favor of preload.

This is linux, people. We like tiny apps that require almost zero load time that you can chain together with pipes. Catering to bloated, poorly coded, Microsoftesque apps shouldn't be an issue for us.

Dammit, this is so easy to demonstrate...

[Junta]

Ok, linux box here, free -m:

total used free shared buffers cached
Mem: 2026 1512 513 0 770 379
    buffers/cache: 363 1663
Swap: 2870 0 2870

slashdot won't seem to let me format the way I want, but run free -m on your own. The cached column is the 379 figure.
Note the 379M number. That is the amount of data read from disk and kept in ram. When an application needs to malloc and no completely free memory, yes it will free up those pages (it ideally picks the cache least likely to be needed again). But absolutely, disk contents are kept in disk cache, but only after load. And no, memory leaks aren't hopelessly pervasive.

What preload does normally happens implicitly during boot. It's hard to demonstrate on init scripts effectively, but log into gnome right after boot, and the disk will thrash like crazy. Log out, kill every last process of that user, log in again. It will be quite dramatic. preload aims for that subsequent experience without the pain of the first.

So what preload brings is simple, and all that has to happen is simple, know which files are relevant to typical usage ahead of time, and be aggressive about 'cat file > /dev/null' if the system during boot has IO idle time. Presumably, the key is identifying which files those are for a particular system.

Linux implicitly aids this, but the user interface side still subjectively 'feels' bogged down because it won't proactively load things it doesn't know you'll need, despite the ability to derive this historical data in user space. If preload takes idle time (let's say, for example, while services with arbitrary sleeps and while waiting for username and password) and proactively gets cache populated, it is more IO work in the aggregate (disk will be hit up for things that will never be needed), but it will feel smoother out of the gate.