OpenBSD Journal

CPU affinity comes to OpenBSD

Contributed by jj on from the one-core-is-for-pr0n dept.

This commit adds support for CPU affinity to OpenBSD.

This will help SMP performance by keeping processes on the same core/CPU if possible, in order to prevent cache flushing and having to repopulate it on the new CPU.
It might also pave the way for things like NUMA and improvements in scheduler locking, since it adds per-CPU scheduler queues. It also will help with hyper-threading performance work later on. Note that it is a work-in-progress, and as the commit message states, there is some guesswork on how to choose the 'best' CPU to land on.

Also note this, from tech@:
After updating your tree with this diff, please remove your kernel build directory before yelling that it's buggy. The dependencies on assym.h for some architectures were still buggy and didn't catch one dependency on a file that changed here, so at least amd64 will break horribly, even with make clean.

//art

(Comments are closed)

Comments

  1. By Anonymous Coward (83.101.57.138) on

    Cool, thanks! What is the overall status of SMP, actually? Is any work being done towards improving locking for instance?

    Comments

    1. By Anonymous Coward (98.127.110.254) on

      > Cool, thanks! What is the overall status of SMP, actually? Is any work being done towards improving locking for instance?

      Yes.

  2. By Vadim Zhukov (77.108.65.40) persgray@gmail.com on

    CVSROOT:        /cvs
    Module name:    src
    Changes by:     guenther@cvs.openbsd.org        2009/03/23 12:51:51

    Modified files:
            sys/arch/amd64/conf: Makefile.amd64

    Log message:
    Add missing dependency generation for assym.h (...the lack of which
    made testers of art's affinity diff go insane)

    ok krw@ miod@

    Comments

    1. By Anonymous Coward (24.255.120.7) on

      > Log message:
      > Add missing dependency generation for assym.h (...the lack of which
      > made testers of art's affinity diff go insane)

      Chiding CVS messages are, without a doubt, the funniest part of the development process.

  3. By Anonymous Coward (71.14.112.13) on

    Good news! Always glad to see SMP work, as they have become more prevalent.

  4. By Danno (192.75.63.254) on

    Nice. Any word on real kernel level threading work? I heard rumblings a few years ago, but as far as I know the OpenBSD pthread library is still entirely user space.

    Comments

    1. By Janne Johansson (jj) jj@inet6.se on www.inet6.se

      > Nice. Any word on real kernel level threading work? I heard rumblings a few years ago, but as far as I know the OpenBSD pthread library is still entirely user space.

      google for rthreads for more rumblings.

  5. By nuintari (64.246.109.61) on

    I seem to remember someone mentioning that PF performance actually suffers on SMP machines, is that still true/was it ever true. And if so, is this expected to help? Seems like it would.

    Comments

    1. By Inigo (85.84.239.102) taromaru@gmail.com on

      > I seem to remember someone mentioning that PF performance actually suffers on SMP machines, is that still true/was it ever true. And if so, is this expected to help? Seems like it would.

      I would also be really interested in getting more information on this issue.

    2. By Ryan McBride (122.217.251.146) mcbride@openbsd.org on

      > I seem to remember someone mentioning that PF performance actually
      > suffers on SMP machines, is that still true/was it ever true.
      > And if so, is this expected to help? Seems like it would.

      This change is about userland processes, while PF is running entirely in the kernel. Kernel code currently receives no benefit from SMP (and actually there is a cost due to the extra locking required), so on a purely PF firewall it's still best to run the standard single processor kernel */bsd rather than /bsd.mp).

      If your firewall box is also doing a lot of userland work, such as running proxies or routing daemons, you may see a benefit from using an SMP kernel, and this change may help those.

      Comments

      1. By Anonymous Coward (83.101.57.138) on

        > This change is about userland processes, while PF is running entirely in the kernel. Kernel code currently receives no benefit from SMP (and actually there is a cost due to the extra locking required), so on a purely PF firewall it's still best to run the standard single processor kernel */bsd rather than /bsd.mp).

        From a technical point of view, is there any reason why the kernel runs single threaded? Is it just a case of no one having volunteered for the work yet, or is there some objection against multiple threads in the kernel?

      2. By Anonymous Coward (64.246.109.61) on

        Thanks Ryan, that clarifies a lot.

        Comments

        1. By Jordi Espasa (84.77.66.237) jordi.espasa@opengea.org on

          Thanks for explanation Ryan.

          ¿What to say about this http://pf4freebsd.love2party.net/pflock/ from Max Laier?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]