[lxc-devel] Memory Resources
daniel.lezcano at free.fr
Tue Sep 1 18:37:01 UTC 2009
Serge E. Hallyn wrote:
> 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.
>>> 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.
More information about the lxc-devel