RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1288507 - free shows used=0 inside OpenVZ containers
Summary: free shows used=0 inside OpenVZ containers
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: procps-ng
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Rybar
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-04 12:51 UTC by Vasily Averin
Modified: 2020-12-15 07:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-15 07:39:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Vasily Averin 2015-12-04 12:51:05 UTC 
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 13:11:08 UTC 
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 15:00:05 UTC 
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
Comment 6 RHEL Program Management 2020-12-15 07:39:01 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.