[lxc-devel] /proc/cpuinfo per cgroup

[Marian Marinov]

On 11/25/2013 05:12 PM, Daniel P. Berrange wrote:
> On Mon, Nov 25, 2013 at 09:09:40AM -0600, Serge Hallyn wrote:
>> Quoting Marian Marinov (mm at yuhu.biz):
>>> Hi guys,
>>> I'm using LXC containers for some of my teaching and I want to have /proc/cpuinfo and /proc/memory based on the cgroup
>>> limits that I have set.
>>>
>>> The idea is that if one container is limited to a cpuset of 0-1 it should see only the first two cores and not all the
>>> cores on the machine.
>>>
>>> The same thing is needed for the memory.
>>>
>>> I simply want my students see the actual resources that they have.
>>>
>>> Does any of you have any suggestions?
>>>
>>> I'm planning to patch the kernel. As far as I can see it, I need to patch the following files:
>>> ./tile/kernel/proc.c
>>> ./sh/kernel/cpu/proc.c
>>> ./x86/kernel/cpu/proc.c
>>> ./mips/kernel/proc.c
>>>
>>> Actually the c_start function.
>>
>> Hi,
>>
>> patching the kernel would be a good exercise.  Historically that hasn't
>> been acceptable upstream - but then tastes and politics change pretty
>> frequently, and what was nacked one year can be enthusiastically
>> accepted two years later...
>>
>> now the alternative is to use fuse to have userspace change what is
>> shown in those files.  Daniel Lezcano years ago had one working.  The
>> code for that is up at https://github.com/hallyn/procfs, however it
>> won't work or even compile as is.  But if you can whip that into a
>> working shape we could hopefully figure out how to ship it with lxc.
>
> In libvirt we went the FUSE route for /proc/meminfo, given the
> kernel guys resistance to changing kernel code for this use case.

Thank you for the good pointers. In my case I think it will be better to support a kernel patch for the kernel.
But I would also try the procfs.

It is always a good idea to try to convince the kernel devs that something is useful :)

>
> Regards,
> Daniel
>