Bug 1250060 - free changed output format and values are different
free changed output format and values are different
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: net-snmp (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Josef Ridky
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 08:23 EDT by Dalibor Pospíšil
Modified: 2017-11-20 10:46 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-07 10:57:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dalibor Pospíšil 2015-08-04 08:23:59 EDT
Description of problem:
# rpm -qf `which free`
procps-ng-3.3.9-6.el7.x86_64
# free
             total       used       free     shared    buffers     cached
Mem:       1017216     613996     403220      29672         72     292988
-/+ buffers/cache:     320936     696280
Swap:      1048572       9408    1039164

# rpm -qf `which free`
procps-ng-3.3.10-3.el7.x86_64
# free
              total        used        free      shared  buff/cache   available
Mem:        1017216      134080      403428       29672      479708      636264
Swap:       1048572        9408     1039164

Note buffers and cached numbers. I cannot find any relation between those two outputs.

Version-Release number of selected component (if applicable):
procps-ng-3.3.10-3.el7
Comment 2 Jaromír Cápík 2015-08-05 14:17:07 EDT
Ahoj Dalibore.

It's for a longer discussion. What you see is absolutely wanted and correct.
The values in the -/+ buffers/cache were dropped completely, as they were misleading and used for undesirable evaluations and wrong assumptions about the memory layout for years. The whole concept of the evaluations was obsolete and didn't match the latest changes in the kernel memory management. One of the values lost its sense since we introduced a more accurate column called 'available', showing the estimation of available memory (=memory that is free or can be freed if needed in order to avoid swapping) and the second lost its sense as the meaning of the 'used' column is different now (we excluded caches and buffers). Previously it was calculated as 'total'-'free', but as the 'free' column became useless due to watermarks (that means the memory reported as free cannot be considered really free), the informative value of the old 'used' column became as low as the informative value of the 'free' column (=very low).
The only problem that makes me unhappy is that we didn't manage to redesign that sooner and so that the old wrong design made it to the first RHEL7 releases.
Comment 3 Jaromír Cápík 2015-08-05 14:21:06 EDT
If you have no objections till Friday, I'll close this as NOTABUG. But if you have, any additional questions, then I'm here for you.
Comment 4 Jaromír Cápík 2015-08-05 15:01:49 EDT
NOTE: After reading all this once more, I see you probably didn't mean the +/- values. The 'cached' and 'buffers' columns changed a bit too. In the default output (width up to 80 characters per line) we report their sum in a common column called 'buff/cache' (they're reported separately in the wide mode -w/--wide). In the old version there was an unwanted patch applied. It was subtracting the Shmem from Cached, but after a very long discussion with the kernel team we agreed it was completely wrong, as that was reinforcing a misconception that memory reported as 'cached' could be considered reclaimable. In fact, the Shmem lives in the page cache and it is not the only unreclaimable part of the cache. That's why the 'available' column born. In addition to that we now report slabs as a part of the 'cached'. And the last note about the 'cached' value is, that nowadays the caches grow aggressively and the increase of the value could also be caused by the package upgrade.
Comment 5 Dalibor Pospíšil 2015-08-13 11:59:33 EDT
As these old 'wrong' values are reported also by net-snmp it is worth of discussion whether net-snmp should (not) change / extend the reporting accordingly.
Comment 6 Josef Ridky 2017-10-11 07:33:02 EDT
Net-SNMP takes all information about available/used memory from /proc/meminfo file.

If information mentioned here are wrong, please tell me where I should take these information from.
Comment 7 Dalibor Pospíšil 2017-10-12 06:17:38 EDT
I have no idea, ovasik or someone from their team could probably give us better answer.
Comment 8 Ondrej Vasik 2017-10-12 09:15:16 EDT
Well - Josef is the current maintainer of net-snmp ... 
I think you may want to ask the former maintainer - Jan Safranek - he maintained net-snmp for a long time, so he probably still knows a lot about it.
Comment 9 Dalibor Pospíšil 2017-10-13 05:05:08 EDT
I meant we want to ask developer of the free tool and as Jaromír left RedHat I asked you as a forwarder to proper person.
Comment 10 Ondrej Vasik 2017-11-06 08:25:18 EST
Although Jaromir left RH, there is new maintainer of procps ;) - moving needinfo on Jan Rybar.
Comment 11 Jan Rybar 2017-11-20 10:46:37 EST
'free' is taking information from /proc/meminfo file too. I can see within code that then the data is processed as described in Jaromír's Comment #2 and Comment #4. It seems that it is only a matter of interpretation of the values to the user.
https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L696

Jaromir mentioned that there already was a long discussion with the kernel team about the representation of values obtained from /proc/meminfo and I haven't found any reason to doubt the results.

In case of any concern, please, do not hesitate to leave any message here or PM me.

Note You need to log in before you can comment on or make changes to this bug.