Slashdot Mirror
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."
I read a guide on the Gentoo forums a while ago about copying different directories into ram to "preload" them.
http://forums.gentoo.org/viewtopic-t-296892.html
I never actually tried it, but I might now that I have 4gb ram! A daemon to help automate this process would be welcome, though.
I find it odd that the article "highly recommends" (RTFA before replying) installing this on a desktop Linux machine, but Vista's implementation is seen as "RAM hogging" and considered "bloat." I'm curious what sort of logical argument underlies this, as the "goodness" of preloading seems to change based upon which operating system it is implemented in. It is *almost* as if there is no logical basis, but, surely that can't be the case with the erudite, level-headed Slashdot crowd, right?
This seems an odd article given preload made it into distros as a standard component for Fedora Core 1 (RHEL3). Its been around since the late 2.4 kernel series was still mainstream. What was the significance of the article? It didn't even update the numbers to a modern hardware config.
Just let it go. This pissing match over innovation serves no useful purpose.
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*
Tsunami -- You can't bring a good wave down!
In Linux, most things never reach the x.0 stage, no matter how mature they are.
what's wrong with trying to drum up a little readership?
For those of us with our own blogs, how on earth do you get readers without tooting your own horn?
They're using their grammar skills there.
When information is power, privacy is freedom.
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.
Trust the Computer. The Computer is your friend.
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.
I Browse at +4 Flamebait
Open Source Sysadmin
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
Sounds like 7 years ago you had no idea how to build a decent computer...
I disagree with both of you. There should not be a need for this. Linux memory management should be closer to optimal for desktop users, but unfortunately the current strategy just doesn't work. It's optimized for servers, paging out interactive apps whenever there's something going on in the background.
In particular, the locatedb daemon makes everything unresponsive because linux caches every file on your file-system it touches, even though it's pretty much guaranteed nobody else needs those files anytime soon. This may be theoretically "optimal" in the general case, but it certainly doesn't feel that way for desktop users. Most desktop users would be more than happy to have background jobs run slower if it didn't impact responsitivity. Also, I believe many people would prefer predictive response-times; it's better for the disk to churn while loading a huge file, instead of it churning everywhere else to page in libraries that have been paged out because the huge file is in memory.
Adding a daemon to predict shared library usage is a step in the wrong direction. Not because it doesn't fix the problem, unfortunately I haven't tried it, but sure, it might even work fantastic. It's a step in the wrong direction because it's a kludge, and not a proper fix for having memory management strategies in the kernel that the users actually want. Unfortunately, fixes to this problem are hard to do, and every time someone tries to do a proper fix, it is debated to death on the kernel mailing list, and then dies slowly as it ages out of tree. For all I know, it's also the right decision, if it should be in-kernel, it should also be *right*. A daemon might be a better place to experiment, and hell, if it solves the problem for 99% of the users, we might not even need to change the current strategy, which is certainly right for servers. After all, we live with kludges other places, such as the X Window System needing to be root and accessing raw kernel memory.
But yeah, memory management is complicated. I doubt you can solve this on a piece of paper. If it works, I'm all for it! Maybe this is a proper kludge?
You could do it in the kernel, but you shouldn't. The kernel keeps track of files using inodes and device numbers, not paths, which may be volatile between reboots (udev+kernel can dynamically assign device numbers to kernel devices, filesystems are identified and mounted by scanning for UUIDs or labels in superblocks, etc). A tracking daemon can monitor system calls and keep a small database with logical paths, access patterns, and so forth; the user-space view of activity tracks intent better so the statistics can be more meaningful.
Moreover the act of caching the file is easily accomplished by a low-priority user-space task which speculatively reads the files which may be referenced soon. In this fashion the kernel memory manager does not need to be changed in any way; we are not creating a new kernel memory pool which would need new logic under memory pressure. In the case that RAM is suddenly needed for storing application pages or an unexpected demand-loaded program binary or library, we can flush these buffered files just like any other cached file; it's not treated any differently. It's just a daemon touching files (with the hope of a benefit in startup times of applications that require them).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON