[Lxc-users] not separeted resources

[Daniel Lezcano]

On 07/12/2010 06:25 PM, atp wrote:
> Nirmal,
>
>
>    
>>>    Per container/per cgroup resource tracking has not been implemented.
>>>        
>> I think only the *tracking* has not been implemented. It would still
>> be possible to configure resources per container using cgroup (cpuset,
>> memory etc.) Please confirm.
>>      
>     Yes, resource constraint has been implemented. That is the main
> purpose of control groups. The tracking of resource consumption by
> control group (as a container has a control group associated with it)
> has not been done.
>
>    Apologies if I was unclear. As always this is based off my
> understanding. Please correct me if I'm wrong.
>    

The process tracking is the cgroup itself. The different controllers are 
plugged on this framework, these are known as subsystems and they make 
use of the cgroup process tracking to assign, account, restrict some 
resources.

The existing subsystems are:

  * physical and swap memory : assign an amount of physical memory
  * network traffic control : choose network traffic bandwidth and 
network priority between cgroups
  * cpuset : assign cpus (exclusive or not)
  * freezer : block all the processes of the container
  * cgroup scheduling : a "nice" at the cgroup level
* and some accounting informations about the cpus and the memory used

The container is tied with a cgroup, so for example if you assign a 
cgroup scheduling priority higher to another container, this one will be 
less responsive than the one competing with it.

lxc gives a thin abstraction layer between the container and the cgroup, 
it is up to the user to know the container subsystems in order to assign 
the right values. That has the advantage to have the lxc code agnostic 
with the cgroup file system moving interface.

The next subsystems and cgroup features are the io nice per cgroup and 
an event file to notify for example the memory has reached a limit. 
AFAICS it is for 2.6.35.

Unfortunately, the cgroup like the proc fs are not container aware and 
several times people is complaining they don't understand why when they 
set the physical memory to 256MB via the cgroup, they don't see the same 
value in /proc/meminfo ?

I don't think there is a nice solution for this right now, and as Andrew 
said we experienced with the fuse /proc overriding the /proc but it 
showed quickly its limits.

Thanks
   -- Daniel