Date: Wed, 29 Jan 2014 14:27:14 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Garrett Wollman <wollman@csail.mit.edu>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Big physically contiguous mbuf clusters Message-ID: <20140129222714.GK93141@funkthat.com> In-Reply-To: <CAJ-VmomC5Ge3JwfUsgMrJ_rGqiYxfxR4wWzn5A-KAu7HBsueMw@mail.gmail.com> References: <21225.20047.947384.390241@khavrinen.csail.mit.edu> <CAJ-VmomC5Ge3JwfUsgMrJ_rGqiYxfxR4wWzn5A-KAu7HBsueMw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Chadd wrote this message on Wed, Jan 29, 2014 at 14:21 -0800: > On 29 January 2014 10:54, Garrett Wollman <wollman@csail.mit.edu> wrote: > > Resolved: that mbuf clusters longer than one page ought not be > > supported. There is too much physical-memory fragmentation for them > > to be of use on a moderately active server. 9k mbufs are especially > > bad, since in the fragmented case they waste 3k per allocation. > > I've been wondering whether it'd be feasible to teach the physical > memory allocator about >page sized allocations and to create zones of > slightly more physically contiguous memory. > > For servers with lots of memory we could then keep these around and > only dip into them for temporary allocations (eg not VM pages that may > be held for some unknown amount of time.) > > Question is - can we enforce that kind of behaviour? It shouldn't be too hard to do... Since everything pretty much goes through uma we can adopt a scheme similar to what Solaris does (read Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources)... Instead of dealing w/ page size allocations, everything is larger, say 16KB, and broken down from there... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140129222714.GK93141>