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>