> Zlatko Calusic wrote:
> >
> > I'm also pretty sure last few development kernels have some big
> > problems with memory. Looks like kernel looses big amount of memory
> > (7-8 MB or even more) and never finds it back.
> >
> > It's enough to execute ls -alR / to loose massive amount of memory In
> > fact, on 32MB machine, memory problem is so obvious that you don't
> > need any tool to see it (top, free or something). Machine gets slower
> > and you can notice it.
>
> The memory "leak" is probably just excessive growth of the dcache and
> inodes. I'm working on the inode memory management, and will post a
> patch for testing later today. I've implemented very simple dcache
> pruning routine for micro-shrinking the dcache, and it works quite well
> at controlling dcache and inode growth.
>
I can't say I didn't expected answer like this, but... :)
It's true that dcache has some problems with uncontrolled growing, and
I'm looking forward to test your patch concerning that issue.
Now I'll try to convince you, once more, that we deal here with
massive memory leak, too. Of course, I can be wrong, but something
smells very bad in dcache code. :)
In my last test (posted to this list), somehow I didn't manage to
shrink dcache (as seen in /proc/slabinfo output), but that's not true
for every other test I made. I thought something changed in 2.1.54,
but after some more testing, it's obvious that things behave
similarly as with last few kernels.
This time I booted to multiuser state, did some work (xemacs,
netscape...) and then did "ls -alR". After that I ran "init 1" to
switch to single user state.
ps:
UID PID PPID START TT TIME COMMAND
0 1 0 14:25 ? 0:03 init
0 2 1 14:25 ? 0:00 kflushd
0 3 1 14:25 ? 0:04 kswapd
0 2342 1 15:30 ? 0:00 update
0 2343 1 15:30 1 0:00 init
0 2344 2343 15:30 1 0:00 -zsh
0 2364 1 15:30 ? 0:00 /sbin/kerneld
0 2389 2344 15:34 1 0:00 ps -ef
df:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 593213 428743 133827 76% /
/dev/hda6 815566 135707 637727 18% /home
/dev/hda7 815566 13 815553 0% /image
Now look what /proc/slabinfo looks:
slabinfo - version: 1.0
kmem_cache 22 42
tcp_open_request 0 0
sock 1 5
filp 278 294
buffer_head 208 1050
mm_struct 6 31
vm_area_struct 72 126
files_cache 8 14
uid_cache 1 127
size-131072 0 0
size-65536 0 0
size-32768 0 0
size-16384 0 0
size-8192 0 0
size-4096 5 8
size-2048 8 16
size-1024 8 16
size-512 8 8
size-256 15 28
size-128 44 50
size-64 700 1260
size-32 643 1449
slab_cache 7 63
Dcache is shrinked. (?)
And free output looks like this:
free:
total used free shared buffers cached
Mem: 30664 13092 17572 848 172 820
-/+ buffers: 12100 18564
Swap: 104796 244 104552
If you recall that I had around 29MB of free memory if I booted
straight into single user, why then I have only 18MB now???
I'm not talking here about hundred bytes leaked here and there, I'm
missing 11MB and there's no way to get them back!!!
>From that point machine crawls like hell, so I don't need numbers to
see something's wrong.
If you need any additional information, don't hesitate to ask.
TIA for any info you can provide.
Regards,
-- Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr> --------------------------------------------------------------------- Is this a machine? I don't talk to machines! [Click]