[libvirt] [RFC] Memory controller exploitation in libvirt

Nikunj A. Dadhania nikunj at linux.vnet.ibm.com
Tue Aug 31 06:45:50 UTC 2010


On Mon, 30 Aug 2010 18:40:34 +0530, Balbir Singh <balbir at linux.vnet.ibm.com> wrote:
> On Mon, Aug 30, 2010 at 11:56 AM, Nikunj A. Dadhania
> <nikunj at linux.vnet.ibm.com> wrote:
<snip>

> > 4) KVM & LXC
> > ============
> > memory.limit_in_bytes: Memory hard limit
> > memory.soft_limit_in_bytes: Memory limit held during contention
> 
> "held" might not be the right word for soft limit.
How about - Memory limit ensured during contention 
 
> > memory.memsw_limit_in_bytes: Memory+Swap hard limit
> > memory.swapiness: Controls the tendency of moving the VM processes to the
> >                  swap. Value range is 0-100, where 0 means, avoid swapping as
> >                  long as possible and 100 means aggressively swap processes.
> >
> > Statistics:
> > memory.usage_in_bytes: Current memory usage
> > memory.memsw_usage_in_bytes: Current memory+swap usage
> > memory.max_usage_in_bytes: Maximum memory usage recorded
> > memory.memsw_max_usage_in_bytes: Maximum memory+swap usage
> 
> We also have memory.stat, memory.hierarchy - The question is do we
> care about hierarchical control? We also have controls to decide
> whether to move memory on moving from one cgroup to another, that
> might not apply to the LXC/QEMU case. There is also memory.failcnt
> which I am not sure makes sense to export.
memory.hierarchy is being used in libvirt, there is an internal API
(virCgroupSetMemoryUseHierarchy) for enabling. I am not sure if this should be
exported.

memory.stat will be good one for getting the stats. I will add this to the
statistics section.

Nikunj




More information about the libvir-list mailing list