RT Scheduler and Network Namespaces - possible issue
Florin Medrea (Gmail)
florinmedrea at gmail.com
Tue Oct 28 15:13:42 UTC 2014
I have a doubt about a certain issue I encounter on my embedded Linux
*Use case*: Use Network Namespaces on RT Processes
*Environment*: 2.6.35 Linux Kernel + some patches for netns (
*Configuration*: the *CONFIG_RT_GROUP_SCHED* option is activated
In my user space application (RT priority) I attemp to *unshare* to a new
Network Namespace. This fais with *EINVAL*. By debugging with printks in
the kernel scheduler, I found that the *unshare* request is refused at this
(because *rt_bandwidth.rt_runtime* is 0).
Digging more in the trace calls, I see that the bandwidth is initialised
and remains set to 0 during the *can_attach* check. Can someone explain why
the bandwidth is initialised to 0 runtime, whilst initialised to
*global_rt_runtime()* at other places in *sched.c* (
As a test, I have replaced the 0 value during this *init_rt_bandwidth* call
to *def_rt_bandwidth.rt_runtime* and my *unshare *system call succeeds.
Firsts tests of network namespaces with this workaround seem to work.
*To resume*, my question is related to this code line:
*Why initialise to 0 and not to the global/default value?*
More information about the Containers