Re: Adding just a pinch of icache/dcache pressure...

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Fri, Mar 23, 2001 at 05:17:16PM +0100, Andi Kleen wrote:
> On Fri, Mar 23, 2001 at 05:10:56PM +0100, Jan Harkes wrote:
> > btw. There definitely is a network receive buffer leak somewhere in
> > either the 3c905C path or higher up in the network layers (2.4.0 or
> > 2.4.1). The normal path does not leak anything.
> 
> What do you mean with "normal path" ? 
> 
> And are you sure it was a leak? TCP can buffer quite a bit of skbs, but it 
> should be bounded based on the number of sockets. 
> 
> -Andi

No corrupted packets. I was pretty sure it was a leak once I noticed
that most of my memory got allocated here:

Top 10 of the not yet freed allocations taken from /proc/memleak in an
IKD-patched 2.4.2 kernel a couple of weeks ago:

memleak/01-02-27__15:44:19
74603    buffer.c:1234 
42956    3c59x.c:2232 
13025    dcache.c:598 
12392    inode.c:665 
5921     dcache.c:603 
4480     ll_rw_blk.c:397 
2304     raid5.c:154 
2105     mmap.c:276 
2064     af_unix.c:1340 
1312     file_table.c:62 

Buffer, dcache and inode allocations are all accounted for, I was
expecting the problem there. However the 3c59x.c allocations are not,
each of those buffers is taken from the size-2048 slab so they were
already taking about 88MB. This was after running a backup, but the
backup was already over and the sockets must have been closed. The
backup statistics showed tcp transfer speed to be an average of 75kB/s
instead of the more typical 350kB/s

Before the backup run, (01-02-27__14:41:45)
7679     3c59x.c:2232 

Later that afternoon the switch was fixed and life returned to normal.
I rebooted the next day and ran another backup, this is the top ten
unfreed allocations after that run.

memleak/01-02-28__16:03:03
191764   buffer.c:1234 
13957    inode.c:665 
9684     dcache.c:598 
4620     ll_rw_blk.c:397 
2304     raid5.c:154 
1587     mmap.c:276 
1066     file_table.c:62 
864      raid5.c:322 
846      dst.c:103 
802      dcache.c:603 
...
224      3c59x.c:2232		# not even in the top 10, it is number 19


I don't have any more numbers, and can't reproduce the situation anymore.

Jan