Interesting (and weird) kernel behavior about hugepage pool at kernel 3.13

[Tony Guan]

First off: uname -a

Linux xguan-wsl 3.13.0-112-generic #159-Ubuntu SMP Fri Mar 3 15:26:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

As the ZGC (cr.openjdk.java.net/~pliden/zgc/) is opensourced, I was curious enough to build it and run it for the first time in my life.

Yet before I can make it work, I need to config the page pool to have the required number pages (say, 9216 pages), then the weird thing happens:

It seems that the nr_hugepages is incremented little by little whenever I touch it:

The first time I run this command:
echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages; cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

I got a 20 back.

Then second time I run this:
32

But when I run cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages alone, that number will be stuck to 32 (as a cross-checking, "cat /proc/sys/vm/nr_hugepages" gives out the same number too).

I understand the kernel is trying hard to accommodate to the big page number that I wanted, and I may not get the desired huge page number I want immediately, but this behavior seems to be weird in that you have to write to it in order for the kernel to do some work.

Just want to check if anybody else is observing the same thing?

Thanks.

[Tony Guan]

Update: upon a reboot, I managed to reserve the huge pages with one shoot so this is not a blocker for me now.

But still, that 'no whipping, no go' is weird...

[Leela Mohan]

Before the reboot, /proc/buddyinfo would have possibly explained this case.