RFR: 8305770: os::Linux::available_memory() should refer MemAvailable in /proc/meminfo
Yasumasa Suenaga
ysuenaga at openjdk.org
Fri May 5 23:30:24 UTC 2023
On Wed, 26 Apr 2023 13:12:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> `os::Linux::available_memory()` returns available memory from cgroups or sysinfo(2). In case of the process which run on out of container, that value is based on `freeram` from sysinfo(2).
>>
>> `freeram` is equivalent to `MemFree` in `/proc/meminfo` [1]. However it means just a free RAM. We should use `MemAvailable` when we want to know how much memory is available for the process [2]. `MemAvailable` is available in modern Linux kernel, and it has been backported some older kernels (e.g. RHEL). In `sar` from sysstat, it refers that value and shows it as `kbavail` [3].
>>
>> AFAIK PhysicalMemory event in JFR depends on `os::Linux::available_memory()`, and it is used in automated analysis in JMC. So the JFR/JMC user could misunderstand physical memory was exhausted even if the memory was available enough.
>>
>> [1] https://github.com/torvalds/linux/blob/c9c3395d5e3dcc6daee66c6908354d47bf98cb0c/fs/proc/meminfo.c#L59
>> [2] https://docs.kernel.org/filesystems/proc.html?highlight=memavailable
>> [3] https://github.com/sysstat/sysstat/blob/ac1df71ca252c158e8d418ded93e5ed52f5e8765/rd_stats.c#L325-L328
>
> We could also just bypass the compiler thread creation question for now. Let the compiler continue to use the old metric when calculating its thread count, but let all other users of os::available_memory() the new one.
@tstuefe @robcasloz
I updated this PR to implement both `free_memory` and `available_memory`. In Linux, `free_memory` refers MemFree (equivalent with older `available_memory`), and `available_memory` refers MemAvailable. In other platforms, `free_memory` proxies `available_memory`. And also `CompileBroker` uses `free_memory` rather than `available_memory`. Some GHA checks were failed, but I think they are not caused by this change.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13398#issuecomment-1536901248
More information about the hotspot-compiler-dev
mailing list