NUMA Support is there in FreeBSD.

Lev Serebryakov lev at
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>

More information about the freebsd-hackers mailing list