random-state.net

Nikodemus Siivola

<< next | top | previous >>

SB-CPU-AFFINITY #
hacking, October 29th 2008

Those wanting control over which CPUs threads run on (and are also lucky enough to be running SBCL on Linux) can give SB-CPU-AFFINITY a try.

Usage:

(asdf:oos 'asdf:load-op :sb-cpu-affinity)

(use-package :sb-cpu-affinity)

(with-cpu-affinity-mask (mask)
  (print mask))

(with-cpu-affinity-mask (mask :save t)
  ;; Remove all
  (clear-cpu-affinity-mask mask)
  ;; Set CPU 0.
  (setf (cpu-affinity-p 0 mask) t))

(with-cpu-affinity-mask (mask)
  (print mask))

(with-cpu-affinity-mask (mask :save t)
  ;; Only odd CPUs in mask.
  (dotimes (cpu (cpu-count))
    (setf (cpu-affinity-p cpu mask) (oddp cpu))))

(with-cpu-affinity-mask (mask)
  (print mask))

Caveat: memory malloc'ed for the CPU masks (per call to GET-CPU-AFFINITY-MASK or WITH-CPU-AFFINITY-MASK) is never released currently, as doing that causes glibc to complain about a double-free, and breaks SBCL. That's a leak of 128 bytes each time — but so long as you only set the affinity mask once per worker thread (and use pooling), it should be a non-issue.

If someone has an insight as to why this is so, and what should be done about it... I'd love to hear.