Re: [lxc-devel] Memory Resources

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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?

-serge