Messages in this thread | | | Subject | Re: Memory leak in 2.1.54 | From | Zlatko Calusic <> | Date | 09 Sep 1997 15:56:58 +0200 |
| |
Bill Hawes <whawes@star.net> writes:
> 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]
| |