lkml.org 
[lkml]   [2005]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: VM disk cache behavior.
On Tue, Feb 08, 2005 at 12:06:14PM -0500, jon ross wrote:
> I have an app with a small fixed memory footprint that does a lot of
> random reads from a large file. I thought if I added more memory to
> the machine the VM would do more caching of the disk, but added memory
> does not seem to make any difference. I played with some of the params
> in /proc/sys/vm and none of them seem to have any effect.
>
> I tired both a 2.4.20 & 2.6.10 kernels with no difference.
>
> The machine is a Dell 2560. I tired memory configs of 512M, 1G, 4G and
> the average read-times do not change.

Could we get some quant here? How small is "small"? How large is
"large"? What are you measuring? What are the results? Does the app
re-use the same data, or is its use a one-time deal?

> Do I need to set/compile anything to allow the VM to use the memory?

No, the Linux VM system should automatically cache for you.

> If is was a way to tell how much memory the VM is using for a drive
> cache I could at least tell if my kernel is miss-configured or my app
> sucks.

Check out the commands "free", "vmstat 1", "top", the contents of
/proc/meminfo, the output of Sysrq-M.

Most likely is that your app isn't behaving in a cache-friendly way. If
your file will fit in memory, just fault it in sequentially (wc -l file)
and then your app should cook. If you're not going to fit in memory,
the vm caching will probably only help if you have some reuse; you could
develop a pre-faulter to get your IO started ahead of time, but that's
generally nontrivial.

-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.364 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site