free: regression due to a different calculation of Used memory

Hi,
one of our customer has noticed that behavior of free(1) has changed and
the reported Used value doesn't correspond to their expectation.

The new behavior has been introduced by
https://gitlab.com/procps-ng/procps/-/commit/6cb75efef85f735b72e6c96f197f358f511f8ed9
which doesn't explain reasoning behind this change unfortunately.

Why is that a problem? From the usability point of view the value might
be seriously undervalued because shmem is not considered as a used
memory. Let me quote from the customer report 

: Since shared memory is not taken into account this can be misleading
: and causes customers to challenge our (internally on MemAvailable based)
: alerts.

From a semantic point of view it is quite hard to understand what the
value is actually trying to represent. I assume that reducing the page
cache and buffer cache aims at providing a memory usage which doesn't
include easily reclaimable memory. In other words something like
kb_main_total-kb_main_available.

Shmem doesn't really fit well into that model IMHO a) memory reclaim
usually tries to avoid swapping out memory b) this is completely off on
swapless systems or in situations where anonymous + shmem doesn't fit
into swap.

I have also noticed that kb_main_cached = kb_page_cache + kb_slab
which looks problematic as well. kb_slab will include also unreclaimable
slab so this is not really a cache. If you wanted to consider
reclaimable slabs then I would expect kb_slab_reclaimable but even then
this looks like potentially problematic for people relying on the
previous semantic which really denoted the page cache.

What would be your suggestion to address these problems?

Thanks!
-- 
Michal Hocko
SUSE Labs