[libvirt] [PATCH] get memory in openvz driver

Evgeniy Sokolov evg at openvz.org
Thu Aug 14 14:08:31 UTC 2008


> On Wed, Aug 13, 2008 at 12:50:33PM +0400, Evgeniy Sokolov wrote:
>> OpenVZ has several parameters for memory management. All of them can be 
>> configured independetly.
>>
>> Patch allow to get configuration of memory from container config and 
>> then calculate total usage of memory.
>>
>> It is open question how to manage memory?
> 
> Basically the 'memory' as shown by libvirt should correspond to 
> the 'Total' seen inside the guest when running 'free'. 
> 
> eg
> 
> # free
>              total       used       free     shared    buffers     cached
> Mem:        524288      34676     489612          0          0          0
> -/+ buffers/cache:      34676     489612
> Swap:            0          0          0
> 
> In this case 'memory' is 524288 kb.
> 
> This looks to correspond to OpenVZs  'PRIVVMPAGES' pages parameter.
It may be configured what will be shown in /proc/meminfo inside container.
Memory from node, total memory or privvmpages. Privvmpages is default.
> 
>> +openvzFreeUbParam(struct openvz_ub_param *ub)
>> +{
>> +    if (ub == NULL)
>> +        return;
>> +#define FREE_P(x) if (ub->x != NULL) VIR_FREE(ub->x);
> 
> This is not required.  VIR_FREE is happy to accept a NULL 
> and will do nothing. Just call VIR_FREE directly without
> testing for != NULL.
> 
>> +/* calculate guaranteed memory for container
>> +*/
>> +int
>> +openvzUb2Memory(struct openvz_ub_param *ub, unsigned long *memory)
>> +{
>> +    unsigned long lowmem, mem, allmem;
>> +
>> +    if (ub->oomguarpages == NULL ||
>> +        ub->kmemsize == NULL ||
>> +        ub->tcpsndbuf == NULL ||
>> +        ub->tcprcvbuf == NULL ||
>> +        ub->othersockbuf == NULL ||
>> +        ub->dgramrcvbuf == NULL ||
>> +        ub->lockedpages == NULL)
>> +        return -1;
>> +
>> +    lowmem = ub->kmemsize->limit +
>> +             ub->tcpsndbuf->limit +
>> +             ub->tcprcvbuf->limit +
>> +             ub->othersockbuf->limit +
>> +             ub->dgramrcvbuf->limit +
>> +             ub->lockedpages->limit * get_pagesize();
>> +
>> +    mem = ub->oomguarpages->barrier * get_pagesize();
>> +    allmem = mem + lowmem; //in bytes
>> +    *memory = allmem / 1024; //in kb
> 
> Summing all the different memory limits together is wrong - this will
> make it impossible to implement a 'setMemory' operation because you've
> now no way of deciding which parameter to set.
It is correct calcuation of total memory.
Because of non-obvious implenetation of 'setMemory', I have asked 'how 
to manage memory' in begining.
I propouse to set some portion of 'memory' to each limit.
> 
> In my testing the total memory inside a OpenVZ container seems to 
> correspond to the 'lockedpages' parameter, so we should just return
> that value.
How did you get total memory?
Most big part of memory is oomguarpages (by default). Lockedpages is 
about %1.
> 
> Since you convert to 'bytes' before converting back into kb, you'll
> potentially overflow a 'long' on 32-bit platforms. You should use
> 'unsigned long long' instead to be safe.
yes, you right.
> 
>> +int
>> +openvzUb2MaxMemory(struct openvz_ub_param *ub, unsigned long *memory)
>> +{
>> +    unsigned long lowmem, mem, allmem;
>> +
>> +    if (ub->privvmpages == NULL ||
>> +        ub->kmemsize == NULL ||
>> +        ub->tcpsndbuf == NULL ||
>> +        ub->tcprcvbuf == NULL ||
>> +        ub->othersockbuf == NULL ||
>> +        ub->dgramrcvbuf == NULL ||
>> +        ub->lockedpages == NULL)
>> +        return -1;
>> +
>> +    lowmem = ub->kmemsize->limit +
>> +             ub->tcpsndbuf->limit +
>> +             ub->tcprcvbuf->limit +
>> +             ub->othersockbuf->limit +
>> +             ub->dgramrcvbuf->limit +
>> +             ub->lockedpages->limit * get_pagesize();
>> +
>> +    mem = ub->privvmpages->barrier * get_pagesize();
>> +    allmem = mem + lowmem; //in bytes
>> +    *memory = allmem / 1024; //in kb
> 
> Likewise this should simply use the lockedpages parameter I believe.
> 
> What is the difference between a 'barrier' and a 'limit' in openvz
> config ?  Would it make sense to map 'memory' to the 'barrier' and
> 'maxmemory' to the 'limit' ?
Barrier & limit are soft and hard limits.
Barrier is guarantee availability of resources. When resource is grown 
up to barrier, it can grow more resurce within grace period, but not 
more than limit.

Memory for application:
oomguarpages & vmguarpages - barrier has matter. It is guarantee number 
of pages. Limits should be always very big - 2147483647.
When the whole node is in out of memory, kernel may don't allow to 
allocate memory or kill container process.
Container may allocate more memory if memory on whole node is available,
  but no more than privvmpages.

> 
> 
>>  
>> @@ -262,6 +264,10 @@ static int openvzDomainGetInfo(virDomain
>>          }
>>      }
>>  
>> +    openvzGetMemory(dom->conn, strtoI(dom->name), &(info->memory)) ;
>> +    openvzGetMaxMemory(dom->conn, strtoI(dom->name), &(info->maxMem)) ;
> 
> Can't you use  'vm->vpsid' and avoid the strtoI() call ?
vm->vpsid = -1 when VM is stoped.

> 
> It seems it would be more efficient to call openvzReadUbParams()
> and openvzUb2Memory() & openvzUb2MaxMemory directly, rather than
> calling out to  openvzGetMemory() and openvzGetMaxMemory() since
> it would avoid reading the config file twice - you can also get
> the nrVirtCPUs at the same time.
Yes, we can read memory once. But get number of CPUs is little complicated.
> 
> Regards,
> Daniel




More information about the libvir-list mailing list