On 03/31/2017 10:16 AM, Peter Steele wrote:
As you can see, the sched_setscheduler() call fails with an EPERM
error. This same app runs fine on the host.
Ultimately I expect this app to fail when run under my container since
I have not given the container any real time bandwidth. I had hoped
the option
lxc.cgroup.cpu.rt_runtime_us = 475000
would do the trick but this option is rejected with anything other
than "0". So presumably this isn't the correct way to give a container
real time bandwidth.
I have more experience with the libvirt-lxc framework and I have been
able to enable real time support for containers under libvirt. The
approach used in this case involves explicitly setting cgroup
parameters, specifically
/sys/fs/cgroup/cpu/machine.slice/cpu.rt_runtime_us
under the host and
/sys/fs/cgroup/cpu/cpu.rt_runtime_us
under the container. For example, I might do something like this:
echo 500000 >/sys/fs/cgroup/cpu/machine.slice/cpu.rt_runtime_us
--> on the host
echo 25000 >/sys/fs/cgroup/cpu/cpu.rt_runtime_us --> on a container
These do not work for LXC based containers though.
The test code I'm running can be simplified to just this simple sequence:
#include <stdio.h>
#include <sched.h>
int main() {
struct sched_param param;
param.sched_priority = 50;
const int myself = 0; // 0 is the PID of ourself
if (0 != sched_setscheduler(myself, SCHED_FIFO, ¶m)) {
printf("Failure\n");
return -1;
}
printf("Success\n");
return 0;
}
On a container with RT support enabled, this should print "Success".
Am I correct in assuming LXC *does* provide a means to enable RT
support? If not, we will need to another approach to this problem.
Peter
_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users
