Bug 1288507 - free shows used=0 inside OpenVZ containers
free shows used=0 inside OpenVZ containers
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: procps-ng (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jan Rybar
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-04 07:51 EST by Vasily Averin
Modified: 2017-12-01 21:08 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 Vasily Averin 2015-12-04 07:51:05 EST
could you please backport following patch from mainline procps-ng git:
https://gitlab.com/procps-ng/procps/commit/05d751c4f076a2f0118b914c5e51cfbb4762ad8e

Description of problem:
under certain conditions free/top shows used=0 inside RHEL7-based OpenVZ containers.

CT-193-bash-4.2# free
              total        used        free      shared  buff/cache   available
Mem:         303104           0        7712       54956      295392       30936
Swap:        303104      215336       87768

This happen because OpenVZ kernel adjust /proc/meminfo output inside container, 
Containers shares host memory effectively, but some memory-related parameters are not accounted per-container, therefore we cannot generate fully correct values and should use some heuristics to generate adequate meminfo output.

In some situations "Cached" value in meminfo output inside container is calculated as 
cached = total - free - slab
btw we show Buffers = 0 inside containers.

Current procps version uses the same formula to calculate "used" value
used = total - free - buffers - cache - slab

As result "used" will be equal to 0 in such cases, and it confuses our customers.
We're going to minimize chances of described situation in our kernel,
however we would like to ask you to help us:

Following patch from mainline procps-ng git uses SlabReclaimable instead of current Slab
https://gitlab.com/procps-ng/procps/commit/05d751c4f076a2f0118b914c5e51cfbb4762ad8e

Updated procps-ng should not show "used=0" even in worst usecase.

We would ask you to include this patch in next update of procps-ng package. 

Version-Release number of selected component (if applicable):
procps-ng-3.3.10-3.el7
Comment 1 Jaromír Cápík 2015-12-04 08:11:08 EST
Hello Vasily.

I'm unsure whether the above patch is a good solution. It distorts the reality and in the past we wanted to avoid things like that. It would require a discussion with the kernel team and a lot of thinking. It's non-trivial even when it looks so.
Comment 2 Vasily Averin 2015-12-04 10:00:05 EST
Dear Jaromir,
thank you for feedback.

We understand that described problem is OpenVZ specific,
and we'll try to avoid it in our (rhel6 and rhel7-based OpenVZ) kernels.

However we decided to notify you about this trouble too.
Please keep it in mind, and probably you'll fins some alternative solution.

Btw I was unable to reproduce described situation in our test lab,
it was observed on customers node only.  However according to kernel sources described behaviour is not a bug, but expected behaviour for some configurations.

Thank you,
   Vasily Averin

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