[Devel] Re: [lxc-devel] Memory Resources
Serge E. Hallyn
serue at us.ibm.com
Mon Aug 31 09:31:14 PDT 2009
Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> 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
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list