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
-
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/
