Date: Tue, 28 Apr 2015 23:37:22 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Garrett Wollman <wollman@bimajority.org> Cc: Rick Macklem <rmacklem@uoguelph.ca>, FreeBSD Net <freebsd-net@freebsd.org>, Mark Schouten <mark@tuxis.nl> Subject: Re: Frequent hickups on the networking layer Message-ID: <CAJ-VmonNKqiz-r6NHykc3WWebGuAO4B-JMKaqjygtW=JxZx-xg@mail.gmail.com> In-Reply-To: <21824.26416.855441.21454@hergotha.csail.mit.edu> References: <4281350517-9417@kerio.tuxis.nl> <137094161.27589033.1430255162390.JavaMail.root@uoguelph.ca> <21824.26416.855441.21454@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I've spoken to more than one company about this stuff and their answers are all the same: "we ignore the freebsd allocator, allocate a very large chunk of memory at boot, tell the VM it plainly just doesn't exist, and abuse it via the direct map." That gets around a lot of things, including the "oh how can we get 9k allocations if we can't find contiguous memory/KVA/either" problem - you just treat it as an array of 9k pages (or I'm guessing much larger - as you said, like ~ 64k), and allocate that way. That way there's no fragmentation to worry about - everything's just using a custom slab allocator for these large allocation sizes. It's kind of tempting to suggest freebsd support such a thing, as I can see increasing requirements for specialised applications that want this. One of the things that makes netmap so nice is it 100% avoids the allocators in the hot path - it grabs a big chunk of memory and allocates slots out of that via a bitmap and index values. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonNKqiz-r6NHykc3WWebGuAO4B-JMKaqjygtW=JxZx-xg>