Date: Mon, 25 Nov 2002 14:11:18 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Julian Elischer <julian@elischer.org>, Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <3DE2A006.B72CBD93@mindspring.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0211232306410.28833-100000@InterJet.elischer.org> <15841.17237.826666.653505@grasshopper.cs.duke.edu> <20021125130005.A75177@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > This is not entirely true. You can allocate an mbuf chain without > holding Giant if the caches are well populated - and they should be > in the common/general case. You can in fact modify the allocator to > just not do a kmem_malloc() if called with M_DONTWAIT, but I don't > think you'd want to do this at this point. In fact, one of the first changes I make in a kernel when I go to do a networking product of any kind is to allocate the mbufs in machdep.c out of physical RAM, and then pre-link them onto a free-list, instead of using the standard (comparatively very slow) mbuf allocator. > The gist of the argument boils down to the fact that network buffer > allocations have different requirements than general all-purpose > allocations (by design, the last time I checked), and that is why > an mbuf/cluster allocator exists. Everything allocated at interrupt has pretty much the same requirements. The only real difference in mbuf's is that the allocation failure cases are generally better handled than all other allocation failure cases within the kernel (or people would not have been beating up Jeff about a month ago for the kmem_map space issue). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE2A006.B72CBD93>