Date: Tue, 12 Mar 2013 15:23:16 +0100 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r248196 - head/sys/nfs Message-ID: <513F3A54.3090702@freebsd.org> In-Reply-To: <201303121219.r2CCJN5Z069789@svn.freebsd.org> References: <201303121219.r2CCJN5Z069789@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12.03.2013 13:19, Gleb Smirnoff wrote: > Author: glebius > Date: Tue Mar 12 12:19:23 2013 > New Revision: 248196 > URL: http://svnweb.freebsd.org/changeset/base/248196 > > Log: > Use m_get2() to get mbuf of appropriate size. The problem with m_get2() is that it will attempt to use jumbo mbufs larger than PAGE_SIZE if the request size is sufficiently large. In light of the recent issues with jumbo > PAGE_SIZE allocations on loaded systems I don't think it is appropriate to extend this practice further. Anything that needs more than PAGE_SIZE (where PAGE_SIZE == 4K) mbuf space should allocate an mbuf chain with m_getm2(). That is what we have mbuf chains for. Sufficient availability of mbufs > PAGE_SIZE cannot be guaranteed after some uptime and/or a loaded system due to memory fragmentation. Allocation can fail non-deterministically for mbufs > PAGE_SIZE long before smaller mbufs become unavailable due to overall (kernel) memory exhaustion. Mbufs > PAGE_SIZE are not only contiguous in kernel address space but also in real memory address space. They are intended jumbo frames on poor NIC's without scatter-capable DMA engines. When you put the m_get2() function proposal for review and comments I already highlighted these issues and put forward serious concerns about this. Please change m_get2() to limit itself to mbuf allocations <= PAGE_SIZE. -- Andre Please note that I applaud your general clean up of mbuf related allocation functions and users thereof. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?513F3A54.3090702>