Sorry for late reply, I had not time to give feedback until now
 
On Mon, Sep 18, 2017 at 10:33 PM, Arik Hadas <ahadas@redhat.com> wrote:


On Mon, Sep 18, 2017 at 10:50 PM, Martin Polednik <mpoledni@redhat.com> wrote:
The hugepages are no longer a hook, but part of the code base. They
can be configured via engine property `hugepages`, where the value of
property is size of the pages in KiB (1048576 = 1G, 2048 = 2M).

Note that the question is about 4.1 and it doesn't seem like this change was backported to the 4.1 branch, right?

And in fact it seems I have not this in 4.1.5 engine:
 
# engine-config -l | grep -i huge
#

In case it is ok for upcoming 4.2/master, how am I supposed to use it? I would like to use hugepages at VM level, not engine.
Or do you mean that in 4.2 if I set it and specify 2M for the engine parameter named "hugepages", then automatically I will see a custom property inside the VM config section, or where?
Any screenshot of this? 

In the mean time I'm using the "old" style with the hook I found here:
vdsm-hook-qemucmdline-4.19.31-1.el7.centos.noarch.rpm
and
vdsm-hook-hugepages-4.19.31-1.el7.centos.noarch.rpm

It works but it seems not to be correctly integrated with what the hosts sees...
an example
On hypervisor I set 90000 huge pages

In 3 VMs I want to configure 34Gb of Huge Pages and total memory of 64Gb, so I set 17408 in their Huge Pages custom property
Before starting any VM on hypervisor I see

# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   90000
HugePages_Free:    90000
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

When I start the first VM there is the first anomaly:
It becomes:
# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   107408
HugePages_Free:    74640
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

So apparently it allocates 17408 further huge pages, without using the part of the 90000 it already has free.
But I think this is actually a bug in what /proc shows and not real usage (see below) perhaps?
Also, it seems it has allocated 64Gb, the entire size of the VM memory and not only the 34Gb part...
I don't know if this is correct and in case expected... because eventually I can choose to increase the number of huge pages of the VM..

Inside the VM vm1 itself it seems correct view:
[root@vm1 ~]# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   17408
HugePages_Free:    17408
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Note that if I run again on host:
# sysctl -p /etc/sysctl.d/10-huge-pages.conf 

it seems it adjusts itself.. decreasing the total huge pages that in theory it is not possible...?

# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   90000
HugePages_Free:    57232
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Again it seems it has allocated 32768 huge pages so 64Gb that is the total memory of the VM,
I start now the second VM vm2:

At hypervisor level I have now:

# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   107408
HugePages_Free:    41872
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

So again an increment of 17408 huge pages in the total line and a new allocation of 64Gb of huge pages (total huge pages allocated 32768+32768)

BTW now the free output on host shows:
# free
              total        used        free      shared  buff/cache   available
Mem:      264016436   233105820    29194036      190460     1716580    29747272
Swap:       4194300           0     4194300

with "only" 29Gb free and if I try to run the third VM vm3 I get in fact the error message:

"
Error while executing action:

vm3:
  • Cannot run VM. There is no host that satisfies current scheduling constraints. See below for details:
  • The host ovirt1 did not satisfy internal filter Memory because its available memory is too low (33948 MB) to run the VM.
"
Again I run on host:
# sysctl -p /etc/sysctl.d/10-huge-pages.conf 

The memory situation on host becomes:

# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   90000
HugePages_Free:    24464
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

# free
              total        used        free      shared  buff/cache   available
Mem:      264016436   197454740    64844616      190460     1717080    65398696
Swap:       4194300           0     4194300
[root@rhevora1 downloaded_from_upstream]# 

And I can boot now the third VM vm3, with the memory ouput on host becoming:

# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   107408
HugePages_Free:     9104
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

# free
              total        used        free      shared  buff/cache   available
Mem:      264016436   233484996    28810096      190564     1721344    29365052
Swap:       4194300           0     4194300


If I "adjust" with"
# sysctl -p /etc/sysctl.d/10-huge-pages.conf 
vm.hugetlb_shm_group = 36
vm.nr_hugepages = 90000

I get now:
# cat /proc/meminfo |grep -i huge
AnonHugePages:         0 kB
HugePages_Total:   98304
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:     8304
Hugepagesize:       2048 kB

# free
              total        used        free      shared  buff/cache   available
Mem:      264016436   214838508    47453540      190564     1724388    48010936
Swap:       4194300           0     4194300

with a total of 90000 and 8304 pages in line "HugePages_Surp:  " for which I don't ever know the exact meaning...

Any comment?
Thanks,
Gianluca