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

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!

Re:LiveCDs do this...

Several things come to mind when I read the post.

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. If true, then this basically does what? Guesses what you want to use and loads them for me? Decides what I use a lot and makes certain they never fall out of memory? In both cases, someone is not using my resources in an optimum manner.

If I use the price of my first desktop computer and use that to purchase a new computer at Dell I am moving up 40 times in speed, 2x in architecture buss, 4x in cores, blah blah blah. Compared to the last computer (2006) I purchased I can still get something easily double in performance from that.

So, Not sure what you need in performance, but between the stupid amount of computing power and Linux already doing a lot of in-memory caching there might be a pretty small margin for improvement. But I guess what I really struggle with is the idea of someone/something trying to proactively determine what I'm going to use and then force my computer into a certain behavioural pattern that is making assumptions about my use. Sure, it screams marketing demographics, but even without a PR department for Linux I still don't think there is sufficient need for something like this.

Can someone elaborate on practical reasons where this is something I would really need

Re:LiveCDs do this...

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:LiveCDs do this...

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.

Hope...

it doesn't make GNU/Linux as *fast* Microsoft Vista.

Nice but...

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

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.

Blogspam

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:Blogspam

By doing something productive, not spamming me with shit I already knew about. Blog about new information you've generated. Maybe make some charts about disk head position during boot and demonstrate whether I/O is throughput or seek bound. Above all else, don't just copy someone else's shit and translate it into HTML.

Similar?

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

I might be wrong, but similar function in Windows Vista should be "Reload".

Vista users respond positively toward the speed boost everytime we "Reload" their Vista. The downtime and data lost as a result of "Reload" might irritate some disgruntled users, but most of them enjoy the free break at the expense of the company.

Nothing in those Linus thingy could beat that user satisfaction. I might be bias though.

Not sure about the gain

I have a pretty good amount of memory on my current machine - 2Gb - and I mostly just never close any applications, especially with the big ones like Gimp just reusing the already open instance when you open a new file. I suspect that preload would not actually be all that useful for me in practice; I'm still goign to enable it to see if I'm wrong, though.

Difference with readahead?

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?

I don't know what rock you were under, but preload has been available for a while:

preload 0.2 release: 2005-09-01

And it was there before as it was packaged in Gentoo (back when it was still popular) and Suse 9.3

Re:What, what?

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:What, what?

I'm envisioning a sensible sort of preload program in gentoo right now:

*Preloading commonly used data, libraries, and binaries...
gcc OK
make OK
libc-dev OK ... *snip* ...
emerge OK
kernel-src OK
*Preload done, 3827K of USE Flags, 2TB of source code, and one compiler, and firefox to surf forums.gentoo.org for better use flags while you compile loaded into main memory

Re:What, what?

In Linux, most things never reach the x.0 stage, no matter how mature they are.

This reminds me of a geek girlfriend I had... she told me she was 29.9.9.12.1 years old. But when I met her in real life, i was suprised she had a daughter... 17.1.25 years old!

Re:What, what?

(or wherever Microsoft stole it from, if that's the case).

OS X had prebinding before Vista had SuperFetch. And they got the idea from somewhere else.

Just let it go. This pissing match over innovation serves no useful purpose.

Re:What, what?

innovation = first time to do something from your point of view

invention = first time to do something ever

Note how MS is always careful to point out they innovate.

*flush*

Re:What, what?

And what do you call the first time it works properly and reliably?

Fantasy.

Re:What, what?

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?

You mean Linux adapted something from Windows instead of the other way around?

Fundamentally, preload and superfetch are just gussied up versions of the sticky bit which I am sure wasn't unique to unix back in the 70s either.

Re:What, what?

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.

Re:Security Implications?

The normal ramdisk vulnerabilities.

You mean like losing the data after a few hours of no power?

Re:Security Implications?

Only if you run out of cold spray [slashdot.org].

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

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.