LinHES Forums
http://forums.linhes.org/

use tmpfs for /cache
http://forums.linhes.org/viewtopic.php?f=11&t=664		 Page 1 of 1
Author:  jfroebe [ Fri Feb 06, 2004 11:45 am ]
Post subject:  use tmpfs for /cache
Hi,

I'm currently using tmpfs for mythtv cache. This would allow any nonrecently used data to be sent to disk (swap).

If I understand correctly, /cache is used solely for the storage of a tempory tv stream (pause live video, etc) so the loss of this buffer on reboot doesn't matter.

The cpu load has been reduced when I move rewind, fast forward, pause, etc.

The following is from my /etc/fstab, which shows a tmpfs filesystem of 5GB and anyone can write to the directory (this is just a mythtv box so I'm not too terribly worried about someone filling the /cache dir)

tmpfs /cache tmpfs mode=777,rw,size=5G 0 0

One thing to note is that your swap space has to be atleast the same size as the tmpfs and and what the os needs normally. My system has 6GB devoted to swap.
Author:  jfroebe [ Fri Mar 05, 2004 9:54 am ]
Post subject: 
minor but important note, make sure to the cache directory to "/cache" in mythtv-setup as the default "/cache/cache" doesn't exist since the /cache is rebuilt new each time linux boots
Author:  Xsecrets [ Fri Mar 05, 2004 11:06 am ]
Post subject: 
This may be a stupid question, and I may not understand what you are doing, but if you only have one disk why would it be faster or less cpu intensive to write to swap than to the filesystem?
Author:  jfroebe [ Fri Mar 05, 2004 12:55 pm ]
Post subject: 
not a stupid question at all...

tmpfs is a filesystem that resides in RAM but is subject to being swapped out. Mythtv has much better response time when running /cache on tmpfs than on ext2 (with noatime mount option). The most important part of /cache is the chunk that is *currently* being written to. This is where the tmpfs excels at for providing a quick i/o.

Here is a nice write up on tmpfs from Sun http://206.231.101.22/si/reading/tmpfs.pdf

The Linux implementation of tmpfs is very similar to the Solaris implementation.

=========
6. Performance
All performance measurements were conducted a SPARCStation 1 configured with 16MB physical
memory and 32MB of local (ufs) swap.

Table 1 refers to results from a Sun internal test suite developed to verify basic operations of ‘‘NFS’’ file
system implementations. Nine tests were used:
create Create a directory tree 5 levels deep.
remove Removes the directory tree from create.
lookup stat a directory 250 times
setattr chmod and stat 10 files 50 times each
read/write write and close a 1MB file 10 times, then read the same file 10 times.
readdir read 200 files in a directory 200 times.
link/rename rename, link and unlink 10 files 200 times.
symlink create and read 400 symlinks on 10 files.
statfs stat the tmpfs mount point 1500 times.

Code:
                nfs        ufs        tmpfs
Test type       (sec)      (sec)    (sec)
create           24.15     16.44     0.14
remove           20.23       6.94     0.80
lookups          0.45       0.22     0.22
setattr         19.23     22.31     0.48
write           135.22     25.26     2.71
read              1.88       1.76     1.78
readdirs         10.20       5.45     1.85
link/rename     14.98     13.48     0.23
symlink          19.84     19.93      0.24
statfs            3.96       0.27      0.26
Author:  Xsecrets [ Fri Mar 05, 2004 1:15 pm ]
Post subject: 
ahh so the theory being that the most recent part is still in physical memory, not swap, so the 30 sec rewind will hopefully come from ram and not swap, and therefore be faster and require less cpu. hmm interesting.
Author:  jfroebe [ Fri Mar 05, 2004 3:00 pm ]
Post subject: 
very close...

the past 30sec written to /tmp on an ext2 filesystem may very well reside in the filesystem cache. The same with tmpfs.


reads:
===========
the filesystem cache is a prime candidate to be flushed (its size is dynamic) far more frequently, which will require physical disk reads to retrieve the chunk of data.

the tmpfs is less likely to be swapped out (filesystem cache is the first to go), and is roughly on par with normal process memory to being swapped out. So the chances of the chunk of data to be in physical RAM is greater. Also, retrieving a memory "page" that was swapped out has a slightly lower overhead of reading from a filesystem (when the data doesn't reside in filesystem cache) - this is the less number of times the data is copied in RAM and a slightly quicker access to the swap itself

writes:
===========
pretty straight forward:

writes to a filesystem will get written to the write buffer in the filesystem cache.. it will periodically get flushed to disk. (this is why database vendors avoid filesystems in favor of RAW partitions)

writes to a tmpfs will get written to RAM, it is only when that particular chunk of tmpfs is swapped out, that any physical I/O is performed. Returning from a write call is much much faster. (regardless of whether async i/o is used or not - which we aren't using here surprisingly)

Unless there is a shortage of RAM (running mythtv on 96mb RAM for example), using tmpfs for /cache will make a big difference

Placing the swap on a logical volume spread across multiple drives is ideal. Also, using maximal drive optimization via hdparm and the idebus=66 linux kernel option will make a large difference as well (there is a topic on hdparm in this forum that goes into limited detail)


Jason
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/