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

On Monday, 11 December 2017 10:59:18 UTC-8, Tony Guan wrote:
>
> 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...
>
> On Monday, December 11, 2017 at 10:42:43 AM UTC-8, Tony Guan wrote:
>>
>> 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.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to