[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