Date: Tue, 24 Aug 2010 20:37:52 +0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Andre Oppermann <andre@freebsd.org> Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion Message-ID: <AANLkTikBHiQ15CFKhsP4Z=9bRJEP-1_RAJAS4Y3U1GLT@mail.gmail.com> In-Reply-To: <4C724AD9.5020000@freebsd.org> References: <AANLkTikrbCFHz-CnuYcgH2JzpeH5hob0Aa2y5dwn3Hvv@mail.gmail.com> <AANLkTikYMU=wML_z=HDnkUF1PGYMVa1q-QWTrkxD%2B7EP@mail.gmail.com> <20100822222746.GC6013@michelle.cdnetworks.com> <AANLkTi=t%2BnG8isp1nf2aBec%2BFwomApNt0NBPO8LqZ%2B=9@mail.gmail.com> <4C724AD9.5020000@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 August 2010 18:18, Andre Oppermann <andre@freebsd.org> wrote: > It seems the 4k clusters do not get freed back to the pool after they've > been sent by the NIC and dropped from the socket buffer after the ACK has > arrived. =A0The leak must occur in one of these two places. =A0The socket > buffer is unlikely as it would affect not just you but everyone else too. > Thus the mbuf freeing after DMA/tx in the bce(4) driver is the prime > suspect. They don't stay leaked though. Killing the offending process sees mbuf's eventually returned. It isn't immediate though. It may be related to timing out existing socket connections or something? I haven't yet brought up the second box enough to start passing test traffic, so I can't provide any further details than this. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikBHiQ15CFKhsP4Z=9bRJEP-1_RAJAS4Y3U1GLT>