site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Aug 15, 2005, at 10:46 AM, Michael Tuexen wrote: Dear all, I have a simple question: But netstat -m gives for example: [PowerMac:/] tuexen% netstat -m 330 mbufs in use: 325 mbufs allocated to data 1 mbufs allocated to packet headers 3 mbufs allocated to socket names and addresses 1 mbufs allocated to Appletalk data blocks 376/848 mbuf clusters in use 1778 Kbytes allocated to network (46% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Thank you very much for your help. Best regards Michael -Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Normally a used cluster element is one where there exist an mbuf which has a pointer to the cluster element. This happens at least when you get it with m_mclget or the corresponding macro. This would than mean that the number of uses mbufs is not larger than the number of used mbuf clusters. Why can it happen that the number of mbuf clusters is larger than the number of mbufs? If you see this GROW over time then it may just be buggy code that's leaking clusters. if it's pretty static then I have a theory: I could see this if a network driver allocated clusters for DMA-ready hardware that can't work on mbufs directly. I ran into this with a card that had the notion of 3 buffer sizes but always started a received frame (even large ones) with one of the small buffers followed by a chain of large ones. Given this strange chaining I couldn't given it mbufs directly (via mbuf memory descriptors) because the hardware would chain large buffers after a small one for large frames. This put the hardware chaining at the wrong level to use mbufs directly. Handing it bare clusters of various sizes and attaching them to an mbuf after the frames are received was the best fit I could come up with. It worked well but did produce the effect you are seeing here of mbuf-less clusters being allocated. If I'm right you are seeing memory waiting for DMA. This email sent to site_archiver@lists.apple.com