On Thu, 17 Feb 2000, Mike Galbraith wrote:
> If you'd like, I can extract ikd (large) and send it so you can try
> memleak. It can give you allocation when/where data.
Thanks, I applied it and it was very interesting.
It looks like line 477 in net/packet/af_packet.c is allocating
like crazy without much being freed.
First: when the "TLAN: Couldn't allocate memory for received data"
messages come and I after a while pull the network cable and
thereby stop the tlan-messages, the system is still useless. A simple
cat command still gives bash: fork: Cannot allocate memory for as long
as 10 minutes after I pulled the plug. It sure looks like a mm/slab-freeing
bug to me. It's not like I'm all out of memory at all. And after a while
the system comes back to live again with saner slabinfo and memleak
numbers.
Here's the last top-memleak numbers I logged right before the system
went back to normal:
14553: af_packet.c:477
6339: buffer.c:1105
5656: tlan.c:1196
4771: memory.c:1004
2295: filemap.c:538
2120: af_unix.c:1240
(the first number being the allocation count).
An hour earlyer when the tlan-messages first occured it looked
like this:
6242: memory.c:1004
3688: buffer.c:1105
3410: af_packet.c:477
3239: filemap.c:538
1514: tlan.c:1196
1457: mmap.c:242
and 7 minutes before that again the top leak-numbers was (quite normal):
6431: memory.c:1004
4638: buffer.c:1105
2658: filemap.c:538
1520: mmap.c:242
1081: file_table.c:82
926: dcache.c:438
881: filemap.c:1797
820: memory.c:782
762: filemap.c:1351
701: af_packet.c:477
As allways, I can apply debug-patches and/or provide more info on
request.
-- Jorgen- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:19 EST