[Devel] Re: [lxc-devel] Memory Resources

[Daniel Lezcano]

Daniel Lezcano wrote:
> Serge E. Hallyn wrote:
>   
>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>   
>>     
>>> Serge E. Hallyn wrote:
>>>     
>>>       
>>>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>>>   
>>>>       
>>>>         
>>>>> Krzysztof Taraszka wrote:
>>>>>     
>>>>>         
>>>>>           
>>>>>> Okey.
>>>>>> I made few tests and this two ways work:
>>>>>>
>>>>>> First way:
>>>>>> =======
>>>>>> lxc. smack enabled, policy loaded. cgroup not labeled.
>>>>>>
>>>>>> a) start container
>>>>>> b) mount cgroup inside container
>>>>>> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo
>>>>>> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup).
>>>>>>
>>>>>> this step can be done inside lxc tools ;)
>>>>>>
>>>>>> Second way:
>>>>>> ==========
>>>>>> lxc. smack enabled, policy loaded. cgroup not labeled.
>>>>>>
>>>>>> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V
>>>>>> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus,
>>>>>> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label
>>>>>> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with
>>>>>> host label to do not allow read them.
>>>>>> b) start container
>>>>>> c) mount cgroup inside container
>>>>>> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo
>>>>>>
>>>>>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on
>>>>>> the admin policy.
>>>>>>
>>>>>> I think that the first solution is more automatic and can be done by lxc
>>>>>> tools (maybe command line switch? I can prepare a patch for that.
>>>>>>         
>>>>>>           
>>>>>>             
>>>>> I do not know smack, what does smack here ? Will this solution avoid 
>>>>> the container to overwrite /proc/meminfo by remounting /proc ?
>>>>>     
>>>>>         
>>>>>           
>>>> Right, in the first way he is labeling the whole cgroupfs with a label
>>>> which prevents the container from mounting it.  In the second way,
>>>> the specific files are labeled.
>>>>   
>>>>       
>>>>         
>>> Ah, got it ! :)
>>>
>>> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this  
>>> case. So we can address the entire /proc specific informations. For  
>>>     
>>>       
>> I agree, nice idea.  And hopefully pretty simple to whip up for the
>> meminfo and cpuinfo files as an example.
>>
>> Are you thinking a fuse fs which takes a config file, holds an open
>> ref to its ancestor /proc, and for each file looks in a config file to
>> decide whether to show userspace:
>> 	1. nothing
>> 	2. the underlying file, unprocessed
>> 	3. a simple ascii file instead
>> 	4. the underlying file, processed?
>>   
>>     
>
> Yes, exactly :)
> But, I am not sure how to retrieve the container context, I mean how to 
> pick and return the right information.
> eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs 
> should process /cgroup/foo/(somefiles), how to know the request is 
> coming from 'foo' without doing multiple mount, one in each container ?
>
>   
>>> example, like the /proc/meminfo, there is the /proc/cpuinfo. If you  
>>> restrict the usage to a subset of your cpus with cpuset and you look at  
>>> /proc/cpuinfo, you see all the cpus; it is not a big problem until a  
>>> computation application looks at this file and choose to fork(n cpus)  
>>> and set the affinity of each process to each cpu ... AFAIR, this is the  
>>> case for HPC applications.
>>>     
>>>       
Krzysztof,

what do think about this solution ?
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers