CPU Pinning for lxc monitor process

LXD
1

Hi, I was integrating the CPU pinning option to the OpenNebula LXD Driver, and it seems that the limits.cpu pinning option pins every process of the container starting from its init process, however, the monitor process of the container is not pinned. KVM/libvirt has an emulatorpin tag which allows to pin the emulator itself to specific cores (i think this is somewhat analogous to the monitor process).

Here is some process info. The first container is pinned to cpu 0 and the second one to cpu 1 and 2

    17412   2   [lxc monitor] /var/lib/lxd/containers one-113
    17430   0     /sbin/init
    17501   0       /lib/systemd/systemd-udevd
    17515   0       /usr/sbin/cron -f
    17517   0       /usr/sbin/rsyslogd -n
    17519   0       /lib/systemd/systemd-logind
    17520   0       /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    17858   0       /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220

    22533   3   [lxc monitor] /var/lib/lxd/containers one-116
    22544   1     /sbin/init
    22618   1       /lib/systemd/systemd-udevd
    22637   1       /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    22648   2       /usr/sbin/cron -f
    22649   2       /lib/systemd/systemd-logind
    22653   1       /usr/sbin/rsyslogd -n
    22974   1       /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220

    root@dann1-server:~# lxc config show one-113 | grep limits.cpu
     limits.cpu: 0-0
     limits.cpu.allowance: 100%
    root@dann1-server:~# lxc config show one-116 | grep limits.cpu
     limits.cpu: 1,2
     limits.cpu.allowance: 200%

I would like to pin the monitor process to the same set of cpu as the container. Does LXD provide the option ?

2

No, there is no such option in either LXD or the underlying liblxc.

One thing to keep in mind here is that unlike what you may see with VMs where the emulator/monitor is quite active, that’s not the case at all for LXC/LXD containers.

During normal operation, the monitor actually isn’t executing any code at all, regardless of what may be happening to the container. Its only jobs are:

  • React to PID1 dying in the container (and handle the shutdown/reboot as needed)
  • Receive commands from LXD itself when we need information about the container

The short version is that it’s generally impossible for a user in the container to cause the monitor to do any work, but preventing the monitor from working when needed would slow down LXD itself, therefore it makes more sense to have the monitor use the same cgroup configuration as LXD (which it does).

3

Thanks a lot for the explanation !!