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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/