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."

LiveCDs do this...

[SaidinUnleashed]

This is exactly why live CDs like Damn Small Linux (and Knoppix, if you have a ton of ram) run so fast if you load the CD image to ram. Ram is fast!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Nice but...

[pizzach]

I never had any luck with preload the times I tried it (a year or two ago?). Nowadays I use alltray [sourceforge.net] for preloading often used apps that are a bit chunky such as Firefox or Openoffice. Openoffice also has a built in preload feature...but you can use alltray anyway for the same effect.

Re:Nice but...

[Nemilar]

Alltray and preload are two totally different things. With Alltray, you're talking about keeping the application open, just minimized to the system tray. With Preload, you're talking about caching the binaries/libraries in memory so when you do open the application, it's reading the data from RAM rather than the hard drive. Sure, AllTray moves the load to RAM, but at the cost of entire applications. The point of preload is that it just caches the most commonly used files.

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

[Bondolon]

Vista is typically seen as being pretty memory-hogging to begin with, whereas I've successfully run gutsy with compiz on my EeePC, and it doesn't, even then, have a problem with memory. The article pretty directly says that at the very most, the machine in question was set up to use no more than 87MiB, and out of that it wasn't even using a third.

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

[Anonymous Coward]

Vista's implementation is marketed as being useful for older, slower machines with less RAM, where it actually may be unwanted, and could cause performance issues (unless it's disabled below a certain threshold - it might be). It's only really useful if you have lots of RAM (around 2GB or so). Yes, SuperFetch has an extra mode where it uses a USB-2 stick as a secondary disk cache, but that's not what we're talking about here. That mode is generally perceived as a gimmick.

Linux handles having lots of RAM a lot better than Windows (XP) does, because of differences in the way the caching system was designed. Linux (and OS X) was intended to run entirely from RAM and use little swap. I've run, say, OpenOffice once, not used it for several weeks, and the next time I start it it loads almost instantly, because it was still sitting in the cache. My machines have 2GB of RAM, with much less than 500MB actually in use - the remaining 1.5GB is being used as disk cache. Swap usage is either zero, or very close. Of course, performance goes to hell if you do something that flushes the disk cache, or if you try using such a system on a machine with 256MB of RAM.

Windows, on the other hand, was designed to run almost entirely from swap, and tends to drop stuff from the disk cache when it's not been used in a while, as well as moving stuff out to swap rather aggressively. That works great if you barely have enough RAM to run the OS, but it's terribly wasteful if you have more than enough RAM. In this case, SuperFetch is actually useful, allowing it to catch up to and actually surpass Linux, by monitoring which files are actually used and making sure they're already in the disk cache.

That's great, although nothing new. Other OSes have had this for years (this Linux implementation dates back to 2005, Mac OS X has had it for ages, and neither implementation was original) - Microsoft were just the first to brand it.

TFA said nothing about Vista's implementation.

I think the primary problem people have with Microsoft's implementations is that they're typically very complicated, and have a tendency to degrade over time. XP is the typical whipping boy for this - none of the self-maintaining performance stuff (prefetching, or the prelinker) actually works for longer than about six months, meaning that an XP installation starts off fast, gradually gets faster, and then rapidly slows down as the system tries to speed itself up.

Blogspam

[bziman]

The submitter is the author of the blog, and is merely paraphrasing the whitepaper written by the author of the software -- and that is two years old. Nothing new or interesting here, just someone trying to draw eyeballs to his blog.

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

[Anonymous Coward]

SuperFetch is easy to turn off, and Microsoft made pretty effective improvements to the VM system in Server 2003, which Vista is built upon. It's the System Restore, Shadow Copies, and Indexing services that strangle Vista with continous disk I/O. Power those services off, provide a healthy quantity of RAM, and Vista will be a much more adept multitasking system than XP ever was.

Re:What, what?

[sqrammi]

It's actually a little different than the preload that's been in Gentoo for years. The core functionality is of course the same, but now a daemon runs that caches libraries and updates the linkage periodically. So, it can possibly give much more performance, since everything is always up-to-date. It will be standard in Hardy Heron when it comes out.

Re:LiveCDs do this...

[ozmanjusri]

It felt like I was running XP on a machine with the minimum specs and running bloated software. Even the mouse was jerky.

Something's not right there. Puppy's normally responsive on machines that'd be slow with 98SE.

Re:LiveCDs do this...

[ozmanjusri]

Puppy's like lightning on my Core 2 laptop. If the mouse is lagging, I'd suspect the graphics card/driver. Try selecting a different Vesa mode next time you boot and see what happens.

Re:ramdisk

[arivanov]

I do this on a couple of systems that see only "occasional" use so I can spin down the disks. Works quite well actually.

Re:LiveCDs do this...

[Anonymous Coward]

Make sure you pass the "toram" parameter when you boot the livecd at the kernel load prompt. You can press the various function keys at boot time to find the correct method.

Re:What, what?

[nguy]

You mean Linux adapted something from Windows instead of the other way around? What's next, a sane proactor i/o api?

Not really. Caching policies like this have been around for longer than Windows has even existed. Most of the things that Linux "adopts" from Windows or Macintosh originally came from UNIX or mainframes. Even in 2008, there is hardly an original idea in any of those operating systems. And preload itself is, of course, older than Vista.

You can be mad at Vista for a number of reasons, but SuperFetch is not one of them - I have noticed a decent speed improvement because of it, and look forward to having something similar in Linux.

It's not clear to me why this should be a separate user process; what it's doing is simple enough that whatever is doing can be done directly by the kernel. In fact, I wouldn't be surprised if you could get the same speedups by simply tuning a couple of kernel parameters.

eeepc + preload = less waiting, more performance!

[Ferret55]

tried it out on my little eeepc and it definitely made a difference, on average its sped up all loading times by about 30 percent. This is especially good because i upgraded to a 2gig stick of ram but most programs hardly need that much ram and on average im left with about 1.2 gigs just sitting there doing nothing, now the ram is more productive and the loading time is noticably faster eg. firefox on a cold start without preload took 10 seconds to load before, now on a cold start it loads in 6 :). Also since the cpu is relatively slow it means fetching data and the overhead of moving it around it cut down alot. I'd love to shake the creators hand for this plucky little piece of software :) thanks!

Re:LiveCDs do this...

[Ibn al-Hazardous]

You start with a false presumption. I do not know what distro you use, and can't tell you if that does anything nifty - but "Linux" sure as hell does not do this already. If another app has already loaded as shared library, it may well be in RAM but it can just as well be swapped out. For all other cases, the answer is probably that your shared libraries are not cached or preloaded - and so this will give you quite a speed up.

The thing that eats all your RAM is nothing Linux specific at all, it is your applications asking for more RAM than they are currently going to use. Why should they do such a thing? Well, what do you think memory management would look like if hundreds of apps, daemons and kernel threads ask for two bytes at a time? It'd paint a pretty fragmented picture, so they ask for gobs of pages at a time. Pages seldom touched get swapped out, but still there's an awesome amount of overallocation - thus your memory seems to be 100% allocated 100% of the time.

So, preloading libs that are frequently used is probably going to use your RAM in a more meaningful way unless you already have a problem with constant swapping.

Re:is toram parameter really faster?

[BobPaul]

The series of comments to which you replied is about Linux LiveCDs, which don't require/touch the hard disk unless you explicitly tell them to. Using "toram" or "dochache" or similar kernel switches allows the entire contents of the CD to be loaded to the ramdisk, dramatically speeding up loading and allow one to remove the CD.

Even if your particular LiveCD is set to watch for and automatically use swap partitions, a HD is still significantly faster than an optical drive. If you install Linux permanently to your HD those particular kernel switches no longer do anything.

Re:LiveCDs do this...

[mhall119]

I thought Linux cached used libraries in RAM already, resulting in the appearance that Linux was always using up all my memory but wasn't really

Linux uses a disk cache in RAM to keep from re-hitting the HD for often-accessed files. It actually is using up all your memory that hasn't been allocated to an application (which is good, because unused memory is wasted memory), but it will drop some disk cache space when other applications need more memory.

If true, then this basically does what? Guesses what you want to use and loads them for me?

Essentially, yes. On of the bigger bottlenecks to application startup is disk seek/read times. By performing this action in the background before it is requested, you won't hit that lag time. The new versions of Java are doing something similar to speed up the cold-start time for Java apps.

Another benefit, and I'm not sure if Preload does this, is to arrange the files on the HD so they are not fragmented, and are in the same position on the disk, so that a single (or small number of) read can copy everything into RAM, instead of hitting the disk over and over.

Re:LiveCDs do this...

[EvilRyry]

The kernel already supports hinting like this. Indexing programs should throw the kernel the hint that the files it reads should not be cached. Whether the programs actually do this or not is another matter.

Re:LiveCDs do this...

[billnapier]

Sigh. The reason Linux always reports all your memory as being used in the page cache where it caches pages that are read from block devices (like you hard disk). Physical pages in memory that are unused (as opposed to virtual pages that your application just hasn't accessed yet) are used to store data read from disk in case you need to access it again. If you application starts to actually use pages that it allocated (like accessing things in shared libraries), linux will dump those disk cache pages from physical memory and start using those pages for the data your app needs. It can easily do this because it knows it is just a copy of what is on the disk and could easily be recovered.

Take a look at "Understanding the Linux Kernel" from ORA for 2 excellent chapters on how all this works.