Unconditional messages on large page reservation errors

[Thomas Schatzl]

Hi,

On 24.04.21 14:31, Stefan Johansson wrote:
> Hi Thomas,
> 
> Sorry for the late reply.
> 
> On 2021-04-17 06:11, Thomas Stüfe wrote:
>> Hi all,
>>
[...]
> 
>>
>> Large page reservations may fail at any time os::reserve_memory_special()
>> function is called, e.g. because the large page pool is temporarily
>> exhausted. And os::reserve_memory_special() is a general purpose 
>> function, not only used for the heap. Running out of large pages is not fatal, 
>> since the caller can just fall back to normal page allocation. Which is what we
>> do when reserving the java heap. I think unconditional printouts should
>> only happen in case of fatal errors, when the VM is about to die.
>>
> 
> I don't really agree here since the performance implications of not 
> using large pages are quite big. I think it is fair to issue the warning 
> since in most cases it signals that there is an environment 
> configuration problem. For testing we have the possibility to use 
> -XX:-PrintWarnings and I saw you used that to fix the issue mentioned 
> above.
> 
> Also, what would the use-case for warning() be if not for printing 
> information in non-fatal but problematic situations (which I think this 
> is).

I agree with Stefan here - the performance implications are too big in 
some cases (e.g. in the Java heap case 10-15+%) to just ignore. I also 
agree that the main case for these warnings are typically unintentional 
misconfigurations, so a warning would be appropriate imho.

For fatal issues there is already fatal(), so using warning() for the 
same case does not make sense to me either.

> 
>> The unconditional warning probably made sense in the context of reserving
>> the java heap, if the user explicitly specified UseLargePages. I 
>> propose to
>> change this to either
>> - if large page allocation for the heap fails, trace with info level
>> and fall back to small pages. Leave it up to the user to increase UL and
>> monitor log output to find out about this. This is what we usually do 
>> when
>> system APIs fail.
>> - continue printing the message with error level, but exit the VM. If
>> it's serious enough to unconditionally notify the user, it's serious 
>> enough
>> to stop the VM.
>>
>> I prefer the former. What do you think?
> 
> As I said above, I see a value in warning if you don't get what you are 
> requesting. But I know others that think exiting is a better strategy. 
> If I'm not mistaken ZGC won't start if it can't reserve enough large 
> pages. One thing that I would like to change in this are is for these 
> warnings to be converted to use UL. That way we could turn of warnings 
> on a much finer granularity and we wouldn't have to use jio_snprintf to 
> compose messages.
> 

Agree with Stefan here as well, depending on the implementation a more 
granular approach to these warnings may allow ignoring of particular 
warnings if the user wants.

Thanks,
   Thomas