RFR: 8305770: os::Linux::available_memory() should refer MemAvailable in /proc/meminfo

[Thomas Stuefe]

On Tue, 11 Apr 2023 07:52:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm finding this as "clear as mud". We have from the /proc description:
> 
> > MemFree
> > Total free RAM. On highmem systems, the sum of LowFree+HighFree
> > MemAvailable
> > An estimate of how much memory is available for starting new applications, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone. The estimate takes into account that the system needs some page cache to function well, and that not all reclaimable slab will be reclaimable, due to items being in use. The impact of those factors will vary from system to system.
> 
> Which suggests to me that MemAvailable <= MemFree (as some memory is not actually "available") yet the example preceding the above text has:
> 
> > `MemFree:        21001236 kB`
> > `MemAvailable:   27214312 kB`
> 
> so there is more available memory than there is free memory ???
> 
> And of course sysinfo(2) has:
> 
> > ` unsigned long freeram;   /* Available memory size */`
> 
> so ??? What does "available" mean?

Available means "memory I can make available to you in case you really need it, but right now it is used for transient things like file system caches". Since the OS uses memory not directly used by applications to speed up e.g. fs access, "free" is not really a helpful metric.

That said, while I agree with @YaSuenag that MemAvailable would be a better metric to underpin os::Linux::available_memory(), I am worried about compatibility issues. E.g. if we happen to run on an older kernel, would we fall back to "MemFree"? If yes, would that not cause issues since we now report different numbers? 

The users of os::available_memory() must be carefully analyzed to check what they do with the reported number, and whether we would run into problems if the caller's conclusions are now different. E.g. the number is used to calculate the number of compiler threads, so we have now a behavioral change where on the same box after a JDK patch we could end up with more compiler threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13398#issuecomment-1502901308