[arch-general] What dirs are good to put in a tmpfs?

[Sean Greenslade]

On Thu, Jul 25, 2013 at 11:34:00AM -0400, Leonid Isaev wrote:
> On Wed, 24 Jul 2013 21:27:11 -0600
> Chris Moline <blackredtree at gmail.com> wrote:
> 
<snip>
> > I installed
> > anything-sync-daemon but I have no idea what to sync. Is there a tool
> > that can tell which dirs are being used the most? I'd rather not guess
> > and benchmark, I don't have the patience for that. What are common
> > dirs that would benefit from being in ram?
> 
> It all depends on your usage pattern.
> 
> One procedure which really benefits from being done in RAM is building
> packages, especially large ones like gcc, glibc or qemu.

I generally do this by resizing my /tmp folder to be ~90% of my RAM (add
size=6G to the options in fstab). It won't intrude on anything until you
actually start using it, but be careful that you don't fill it. The
system will start swapping like crazy if you fill it.

> For a regular desktop, people put in RAM ~/.mozilla, ~/.local/chromium (or
> whatever Chrome uses these days), etc. However, in my experience the resulting
> speedup is next to none and not worth the risk of data loss in case of a power
> failure or a system freeze...

I use profile-sync-daemon, but mostly to prevent writes to my SSD. I
don't think you'll get much performance gain from it, especially since
the kernel does pretty aggressive read/write caching with any unused
RAM. 

> The truth is that on desktop machine which does
> not do virtualization, you don't need more than 2GiB or RAM. Remember, memory
> modules do consume power so it may be sensible to remove most of them.

I'm not entirely sure this is what you'd want to do. The system will use
the memory in one way or another. Unless you're _really_ concerned about
power usage, it seems silly to take out RAM.

--Sean

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130725/c4f46efd/attachment.asc>