Re: [lxc-devel] Memory Resources

[Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org):
>   
>> Serge E. Hallyn wrote:
>>     
>>>> 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 ?
>>     
>
> Why without doing one mount per container?  :)
>
> I figure the container can be responsible for the actual mounting,
> if it cares.  The host/kernel should keep it *safe* for the container
> to use unfiltered /proc (, /sys, /cgroup, etc), but the container
> can be responsible for filtering it however much it feels necessary.
>
> (That fits with the 2006 kernel summit pseudo-decree that we are not
> trying to fake a container into thinking it is a real host, only
> make the container useful.)
>
> Are you worried about the extra memory overhead?
>   

Well, I am used to see a single instance of a daemon like sshfs :)
I am not used of fuse, I will play a bit with a trivial fuse-lxcfs to 
see how that behaves with a container.