On 04/05/2017 06:45 AM, Serge E. Hallyn wrote:
I correct in assuming LXC *does* provide a means to enable RT
The kernel has hardcoded checks (which are not namespaced) that
if you are not (global) root, you cannot set or change the rt
policy. I suspect there is a way that could be safely relaxed
(i.e. if a container has exclusie use of a cpu), but we'd have
to talk to the scheduling experts about what would make sense.
(see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/core.c?id=refs/tags/v4.11-rc5#n4164
)
Otherwise, as a workaround (assuming this is the only problem you
hit) you could simply make sure that the RT policy is correct ahead
of time and the priority is high enough that the application is only
lowering it, then the kernel wouldn't stop it. Certainly that's
more fragile. Or you could get fancier and LD_PRELOAD to catch
sys_setscheduler and redirect to an api over a socket to a tiny
deamon on the host kernel which sets it up for you... But certainly
it would be best for everyone if this was supported in the kernel the
right way.
Most of our containers do not require real time support. There are a
couple of cases though where our software does use real time threads
though. We originally were running under libvirt based VMs and real time
support was not an issue in this kind of environment (it was fully
supported). We ported our software to libvirt lxc based containers and
with the appropriate configuration was able to get real time support
working under this environment as well. We want to make one more
transition now to LXC (mainly due to lack of active support for
libvirt-lxc in CentOS). I had assumed this was simply a container
configuration issue but your response makes me think that it's not as
simple as that. Not sure where that leaves us.
Peter
_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users
