slabinfo reports:
inode_cache 189974 243512 480 30439 30439 1 : 124 62
dentry_cache 201179 341940 128 11398 11398 1 : 252 126
However, I am hard pressed to find documentation on how to actually read
this data, especially on a SMP box. Could someone give me a brief
runwdown?
Also, if this memory is cached, wouldn't it make sense if it were reported
as part of the total cached memory in /proc/meminfo? And can this
behavior be tuned so that it uses less of the overall memory?
Thanks,
Josh
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net
On Tue, 20 Mar 2001, Jan Harkes wrote:
> On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> > Greetings,
> >
> > I have a server farm made of identical hardware running pop3 and imap mail
> > functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> > noticed that according to free, our memory utilization went way up. Here
> > is the output of free on the 2.4.2 machine:
> > total used free shared buffers cached
> > Mem: 513192 492772 20420 0 1684 263188
> > -/+ buffers/cache: 227900 285292
> > Swap: 819304 540 818764
> >
> >
> > On the 2.2..18 machine:
> > total used free shared buffers cached
> > Mem: 517256 351280 165976 19920 82820 186836
> > -/+ buffers/cache: 81624 435632
> > Swap: 819304 0 819304
> >
> >
> > Doing the math, the 2.4 machine is using 44% of available memory, while
> > the 2.2 is using only about 14%.
>
> What does /proc/slabinfo report for the number of pages locked down in
> the inode and dentry caches? My machine has pretty much every inode in
> memory and is using close to 50% of my memory for these (214MB/512MB).
>
> These caches do not seem to be counted towards 'reclaimable' memory by
> the new VM and are only pruned when _all_ other attempts to free up
> memory have failed.
>
> This becomes very noticeable on a not very fast, small memory machine
> (i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
> becomes unusable after an updatedb run.
>
> Jan
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
