Big physically contiguous mbuf clusters
Garrett Wollman
wollman at hergotha.csail.mit.edu
Thu Jan 30 03:22:58 UTC 2014
In article <20140129231138$3db6 at grapevine.csail.mit.edu>,
nparhar at gmail.com writes:
>I think this would be very useful. For example, a zone_jumbo32 would
>hit a sweet spot -- enough to fit 3 jumbo frames and some loose change
>for metadata. I'd like to see us improve our allocators and VM system
>to work better with larger contiguous allocations, rather than
>deprecating the larger zones. It seems backwards to push towards
>smaller allocation units when installed physical memory in a typical
>system continues to rise.
In order to resist fragmentation, you need to be willing to dedicate
some partition of physical memory to larger allocations. That's fine
for a special-purpose device like a switch, but is not so good for a
general-purpose operating system. But if you were willing to reserve,
say, 1/64th of physical memory at boot time, make it all direct-mapped
using superpages, and allocate it in fixed-power-of-two-sized chunks,
you would probably get a performance win. But the chunks *have* to be
fixed-size, otherwise you are nearly guaranteed to get your arena
checkerboarded. I'd consider giving 2 GB on a 128-GB machine for
that.
For NFS performance, you'd probably want to be able to take a whole
chunk, read the desired data into it in a single VOP, then pass the
whole thing to the socket layer wrapped in an mbuf.
-GAWollman
More information about the freebsd-net
mailing list