[lxc-users] Enabling real time support in containers

[Serge E. Hallyn]

On Tue, Mar 28, 2017 at 05:32:15AM -0700, Peter Steele wrote:
> 
> >We have a need to create real time threads in some of our
> >processes and I've been unable to configure an LXC container to
> >support this. One reference I came across was to set a container's
> >real time bandwidth via the lxc.cgroup.cpu.rt_runtime_us parameter
> >in its config file:
> >
> >lxc.utsname = test01
> >lxc.include = /var/lib/lxc/centos.conf
> >lxc.network.veth.pair = test01
> >lxc.network.hwaddr = fe:d6:e8:e2:fa:db
> >lxc.rootfs = /var/lib/lxc/test01/rootfs
> >lxc.rootfs.backend = dir
> >lxc.cgroup.cpuset.cpus = 0,1
> >lxc.cgroup.memory.limit_in_bytes = 2097152000
> >lxc.cgroup.memory.memsw.limit_in_bytes = 3170893824
> >lxc.cgroup.cpu.rt_runtime_us = 475000
> >
> >This container starts up fine if lxc.cgroup.cpu.rt_runtime_us is 0
> >(zero). Anything other than 0 is rejected, which means real time
> >threads cannot be created in this container.
> >
> >What am I missing to get this to work? I am using lxc version
> >2.0.6 under CentOS 7.2. The container is being created using a
> >custom CentOS 7.2 image.

Is this using a user namespace or not?

> No takers on this? I assume this is possible? I'm looking for the
> configuration options that would allow code such as this to run :
> 
>     pthread_attr_setinheritsched(&tattr, PTHREAD_EXPLICIT_SCHED);
>     pthread_attr_setschedpolicy(&tattr, SCHED_FIFO);
>     tsparam.sched_priority = sched_get_priority_max(SCHED_FIFO) - 7;
>     pthread_attr_setschedparam(&tattr, &tsparam);
>     rc = pthread_create(&test_thread, &tattr, test, NULL);
> 
> While this code runs fine in my host, it returns a non-zero code on
> my containers, indicating I am not allowed to create real time
> threads. I'm assuming this is a configuration issue in my LXC
> containers since I've seen this same code run under other container
> frameworks. There doesn't seem to be a lot of hits on this topic
> though when it comes to LXC.

Can you strace the failing code and get the exact system call which is
failing?  If you're in a non-init userns, then my guess is in fact the
kernel needs an update - see callso to capable(CAP_SYS_NICE) in
kernel/sched/core.c.  For those to work in a user namespace it'd need to
use ns_capable().