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

208 views
Skip to first unread message

Tony Guan

unread,
Dec 11, 2017, 1:42:43 PM12/11/17
to mechanical-sympathy
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

unread,
Dec 11, 2017, 1:59:18 PM12/11/17
to mechanical-sympathy
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

unread,
Dec 13, 2017, 9:38:27 AM12/13/17
to mechanical-sympathy
Before the reboot, /proc/buddyinfo would have possibly explained this case.
Reply all
Reply to author
Forward
0 new messages