NUMA Support is there in FreeBSD.
Lev Serebryakov
lev at FreeBSD.org
Mon Oct 3 21:40:00 UTC 2011
Hello, Mdf.
You wrote 3 октября 2011 г., 21:34:29:
> Your statement isn't incorrect. What I'm saying is that there's no
> KPI for requesting bound memory because, while the netstat example is
> a fine one for where local memory is desired, the majority [1] of
> processing is not bound to a CPU and so round-robin allocations will
> produce uniform performance results -- that is, not the best possible,
> but not wildly fluctuating as scheduling decisions over different runs
> give different remote memory penalties.
We have exactly the same config at ${WORK}, as Arnaud describes. And
we need to process huge (4Gbit+ wire speed in small -- 100-1000
bytes -- packets) UDP traffic. Without fixed affinity of "netisr"
threads our system drops some packets on the way between DMA-mapped
network card buffers and kernel structures. One big difference: we
use Solaris and it have all needed API, KPI and userland control
utilities to tune system, both kernel-side and userland-side. Even
Solaris, though, could no process such traffic "automagically". We
didn't try FreeBSD, as our ops knows nothing about it (I'm only
FreeBSD fan in team and I'm developer, not operations)...
I wrote this as example, that for some tasks system NEEDS all these
NUMA-specific knobs.
BTW, NUMA-aware allocator in HotSpot (Sun's, errr, sorry, Oracle's
Java VM), added between Java6 and Java7, increased performance for some
workloads up to 300% on 72-way system (SunFire 15K), and gives about
3% performance drop on worst situations :) And it was allocator in
virtual machine! But it would have been impossible without kernel
API, so this changes works well only on HotSpot/Solaris ;-)
Again, I wrote this all to show, that NUMA-awareness could be very
useful on big iron.
--
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>
More information about the freebsd-hackers
mailing list