On Mon, Jul 12, 2010 at 10:20 AM, Daniel Lezcano <daniel.lezc...@free.fr> wrote: > 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 read this as the reporting is not virtualized for container but limits will still apply per container. For instance I can configure 256MB physical memory for container but it won't show up in meminfo or free. The physical limit will still apply. Did I misread? Please clarify. Also let me know if all the cgroup subsystems (network, cpuset, memory etc.) work with lxc containers i.e I can set limits. This will help me make a conscious choice. Appreciate your help. --Nirmal > > 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 > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
