On Wed, 21 Mar 2001, Jan Harkes wrote:
> I've been thinking about this a bit and one possible solution would be
> to significantly lower the cost of prune_icache by removing the
> sync_all_inodes and only let it prune inodes that do not have any
> mappings associated with them. Then it might beco
On Wed, Mar 21, 2001 at 11:42:08AM -0600, Josh Grebe wrote:
> This is what I'm afraid of, in my case we have millions of files that are
> dealt with in no real order, and if cache fragmentation will keep the
> memory from being freed, we're in for problems. This reading was taken
> with the machin
This is what I'm afraid of, in my case we have millions of files that are
dealt with in no real order, and if cache fragmentation will keep the
memory from being freed, we're in for problems. This reading was taken
with the machine having been up for only 5 days. Currently, I show:
inode_cache
> > Lastly, which cache can be reclaimed, and which can't?
>
> Slab cache will shrink if there are whole pages which are empty (it may
> be that they have to be at the end of the cache). It is hard to tell
> from the above numbers if any of the caches could shrink, because it
> depends on the nu
> inode_cache 189974 243512 480 30439 30439 1 : 124 62
> dentry_cache 201179 341940 128 11398 11398 1 : 252 126
1) number of used objects
2) number of allocated objects
3) size of each object
4) number of slabs that are at least partially in use
5) number of slabs that are allocated for the cache
Zou Min writes:
> Then how to interpret slabinfo in 2.2.16 box?
> e.g. grep cache /proc/slabinfo
>
> kmem_cache32 42
> skbuff_head_cache 2676 2730
> dentry_cache 15626 16988
> files_cache 103108
> uid_cache 10127
> slab_cache85
> > slabinfo reports:
> >
> > inode_cache 189974 243512480 30439 304391 : 124 62
> > dentry_cache 201179 341940128 11398 113981 : 252 126
> ^
> |
>
>
Then how to interpret slabi
:: > And can this behavior be tuned so that it uses less of the overall
:: > memory?
::
:: This isn't currently possible. Also, I suspect what we really want
:: for most situations is a way to better balance between the different
:: uses of memory. Again, patches are welcome (I haven't figured ou
On Tue, 20 Mar 2001, Josh Grebe wrote:
> slabinfo reports:
>
> inode_cache 189974 243512480 30439 304391 : 124 62
> dentry_cache 201179 341940128 11398 113981 : 252 126
^
|
> Ho
As far as performance goes, I can only say that my max load is slightly
lower on the 2.4 box then on the 2.2 boxes. Our average load for yesterday
on 2.4 was .23, with a max of 1.11. In comparison, my averages for the
other machines are .27, .27, .23, and .23. The maxes are 1.85, 1.33, 2.06,
1.47.
slabinfo reports:
inode_cache 189974 243512480 30439 304391 : 124 62
dentry_cache 201179 341940128 11398 113981 : 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
run
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.
On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
...
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.
How is the performance difference ?
...
> These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, a
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
14 matches
Mail list logo
