What to do with extra ram on Linux?

[grob49]

I just built a small machine to use for OS testing, web browsing, and some media consumption.

Biostar H77-MU3 MB, i3-3225 CPU with Intel 4000 integrated graphics, 250GB sata disk, and 16 Gb of Ram. I was planning on buying 4 GB (plenty for my purposes), but my local computer supplier had a special on Corsair Vengance DDR3-1600 memory. 16GB for $35.00 with no rebate. Since I've never been able to pass up a good deal, I picked it up.

I'm running LinuxMint 14.1 Cinnamin 64 bit. I'm fairly new to Linux, but I like it so far. System Monitor says I'm using less than 1GB of ram with Chrome browser and VLC open. My question is this: What can I do with all that extra ram? Are there RAM-Disk programs still around? Maybe some sort of disk cacheing? Any suggestions?

[bthylafh]

Linux will automatically use extra RAM for disk cache as you access the drive, so you don't need to do anything special there.

[Flatland_Spider]

You should switch to Firefox.

bthylafh is correct. Linux will cache as much is possible in RAM, so there's not much to gain from a RAM disk.

Does Mint use tmpfs? Newer versions of Fedora do, but I'm not sure about Ubuntu or Mint. Anyway, tmpfs is basically a RAM disk for the tmp folder. Instead of using a folder on the disk drive, tmp is in RAM and backed up by the swap space.

Run more services and a VM or two.

[DancinJack]

You should switch to Firefox.

If he wants to use more RAM, that would fulfill his wish.

[bthylafh]

Here's how to enable tmpfs in Mint:
http://forums.linuxmint.com/viewtopic.php?f=46&t=104060

I don't expect it would speed you up a ton, but it will some, and you certainly have the RAM to spare. Could save you some power usage as well since you won't be spinning up the hard drive as much.

Something else you could do is install Virtualbox and play with virtual machines. You have enough RAM to give each VM 1-2GB and not sweat it. Steam is coming to Linux soon and the most demanding game (so far) is going to be Serious Sam 3 BFE.

[grob49]

Thanks for the responses so far. I might give the tmpfs idea a try. Sounds fairly simple and clever.

I thought about installing VMware and trying some virtual machines, but the more I read about it, it sounds like it might be over my head. Never heard of Virtualbox. I'll try to do some research on it.

Everyone have a great day!

[DancinJack]

If you can run Linux and get around just fine, you can set up and run a VM.

[just brew it!]

As others have noted, you don't really need to do anything. Modern OSes (not just Linux, Windows too!) aggressively use extra RAM to cache recently used data, and in some cases other data the OS thinks you might access in the near future (pre-fetch). That RAM is already being put to use, making your overall experience smoother.

To see a simple example of how this works, reboot the system then try opening a large application (e.g. LibreOffice). Now close the application, then immediately open it again. You'll notice that the second time it opens much faster (nearly instantaneously). This is because the first time you opened it, the OS fetched it from disk; but the second time, it was still sitting in the file cache from the first time you opened it.

As others have noted, you've also got plenty of RAM to run VMs if you want to try out other distros.

Moving /tmp to a RAMdisk (the tmpfs thing) may help a little with certain apps, but personally I wouldn't bother. Temporary files will automatically take advantage of the extra RAM as cache even if you don't explicitly enable tmpfs, and enabling tmpfs may even hurt in some cases since it will take RAM away from what's available for general file caching.

Edit:

You should switch to Firefox.

If he wants to use more RAM, that would fulfill his wish.

In a similar vein, he could try running the KDE desktop. I've been evaluating it myself, and there are some things to like, but also some usability issues; and it is a massive memory pig. Currently torn between making a go of KDE, or trying MATE (or even Xfce).

[jihadjoe]

Isn't there any way to selectively pre-fetch certain applications to the file cache on boot or shortly after?
It'll be a more efficient use of RAM than doing a RAMDISK for sure, and we get the benefits of super fast load times.

[just brew it!]

Isn't there any way to selectively pre-fetch certain applications to the file cache on boot or shortly after?
It'll be a more efficient use of RAM than doing a RAMDISK for sure, and we get the benefits of super fast load times.

I'm not aware of a way to do this.

Handling this in the general case is actually rather difficult, since many Linux apps have a small stub loader (often a shell script) as the thing that gets executed initially; this then goes and runs the actual application. So there's no simple way for the OS to figure out what files need to be pulled in without launching the application for real.

[The Wanderer]

I'm not aware of a way to do this.

The only approach I can think of offhand (based on the question as I understand it, anyway) would be to have a script that reads the necessary files automatically based on a manually-built-and-updated list, e.g.

Code: Select all

for file in \
    "/path/to/mainbinary" \
    "/path/to/library1" \
    "/path/to/library2" \
    "/path/to/datafile" \
    ; do
  cat "${file}" > /dev/null ;
done

, but listing all of the necessary files - especially shared libraries, which can be numerous - would probably be a bit of a headache.

The shared libraries could be easily identified via 'ldd /path/to/mainbinary' and recursing as necessary - but if the path and/or filename change when that library gets updated by the package manager, you'd have to update the list, and it would be easy to miss noticing the change.

Depending on the program, identifying the datafiles could be a trivial or an impractically complex matter.

I'm not at all sure this is remotely worth the effort, really.

[just brew it!]

Yeah, I thought of suggesting something like that too, but figured it was more trouble than it is worth. The ldd tool will chase down shared libraries for you, but for apps that launch via a shell script you're still going to need to read through the shell script to figure out the name of the top-level binary to feed to the ldd tool. Yuck.

Even on a mechanical hard drive load time for most apps is pretty short these days, and if you're using an app repeatedly (which is the situation where you'd care about load times the most) it'll probably be there every time except the first.

[The Wanderer]

Well, I did think of one way to potentially automate it entirely, but it sounds like it would be inefficient and probably overkill.

Essentially, it would be:

* Identify the package name for the program you want to precache. (This is the only non-scripted step.)
* Identify the package file for the currently-installed version of that package.
* Using the system's package-management tools, extract from that package file a list of all installed packages which are depended on by that package.
* Repeat the previous two steps recursively until you run out of new dependencies.
* Using the system's package-management tools, extract from those package files a list of all files installed by any of those packages.
* Run the 'cat filename > /dev/null' loop over that list of files, rather than over one built by hand.

That way, all you'd have to manually maintain would be the package name of the top-level program, and everything else would be taken care of automatically. It wouldn't catch generated files (e.g. mail-client mailbox files or Web-browser cached or session-restore files, which are generally under the user profile directory), but it would handle everything for the program itself.

The downside of this, aside from the overhead involved in accessing the package files themselves every time you want to do the precaching, is that it pulls in everything installed by any of the packages involved - including files which the specific program in question may well not need, such as package documentation (which can be sizable in some cases). It might be better than nothing, but I wouldn't bet on it.

[bthylafh]

If I'm understanding your intent here, you should also maintain a local package mirror so you're not hogging someone else's bandwidth. Or perhaps make sure you've got plenty of space in /var/cache/apt (on a Debian-like distro) so you can keep the newest packages for your installed s/w handy.

[The Wanderer]

Well, yes - AFAIK if you don't have a local copy of the package file for the currently-installed package version, you're doing it wrong. It should never happen by default as far as I'm aware, anyway.

[just brew it!]

The downside is that you'll probably be pulling in an awful lot of stuff you don't need. Help files, content (e.g. clip art if you're pre-caching an office suite), and other seldom-accessed data will get pulled in along with the stuff you want.

The system will also be thrashing the hard drive for a while as it tries to pull all that stuff in, making the system sluggish for a period of time after startup. One of the things I loved about Linux when I first switched to it was that the desktop is very fluid and responsive pretty much as soon as it appears; I would hate to give that up.

Mirror access should not be an issue; the data you need should be in the local apt cache already. There are other reasons why you might want to have a local mirror, but this isn't one of them.

[The Wanderer]

I agree on all counts. Those are among the reasons why, even if this works to speed up program launch, I wouldn't bet on its being better (in terms of total user experience) than doing nothing at all.

I certainly don't recommend the procedure I described; it's just the only way I could think of to automate the precaching process reliably. (Short of writing a daemon - and/or possibly a kernel module - to analyze disk access patterns and precache based on usage, which I think is how Windows does it. But I think Linux does that already to some degree, and even if it doesn't, doing it is far more effort for the return involved than most people are going to consider appropriate.)

[notfred]

Code: Select all

sudo apt-get install preload

[just brew it!]

Code: Select all

sudo apt-get install preload

Ahh, looks like someone's done the work to implement something analogous to Windows' "SuperFetch":

preload is an adaptive readahead daemon that prefetches files mapped by applications from the disk to reduce application startup time

Probably worth a look if you've got spare RAM.