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 767921 - Results are different when testing memtune for twice with the same parameters
Summary: Results are different when testing memtune for twice with the same parameters
Keywords:
Status: CLOSED DUPLICATE of bug 839537
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 826880
TreeView+ depends on / blocked
 
Reported: 2011-12-15 09:08 UTC by Min Zhan
Modified: 2013-01-25 11:29 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 826880 (view as bug list)
Environment:
Last Closed: 2012-07-23 13:42:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Min Zhan 2011-12-15 09:08:37 UTC 
Description of problem:
For the first time, memtune command fails; try with the second time, memtune succeed with the same parameters. I think maybe it is needed to check the user layer's parameters first.

Version-Release number of selected component (if applicable):
kernel-2.6.32-220.el6.x86_64
qemu-kvm-0.12.1.2-2.209.el6.x86_64
libvirt-0.9.8-1.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. # virsh list --all
 Id Name                 State
----------------------------------
  8 vm1                  running

# virsh memtune vm1
hard_limit     : 103000000004 kB
soft_limit     : 103000000004 kB
swap_hard_limit: 103000000004 kB

2. Increase hard-limit value (only need pay attention on the first 4 numbers)

# virsh memtune vm1 --hard-limit 103100000001 --soft-limit 103000000001 --swap-hard-limit 103000000001 
error: Unable to change memory parameters
error: unable to set memory hard_limit tunable: Invalid argument

# virsh memtune vm1
hard_limit     : 103000000004 kB
soft_limit     : 103000000004 kB
swap_hard_limit: 103000000004 kB


3. Increase other 2 parameters to keep the same as hard-limit, and do twice

# virsh memtune vm1 --hard-limit 103100000001 --soft-limit 103100000001 --swap-hard-limit 103100000001
error: Unable to change memory parameters
error: unable to set memory hard_limit tunable: Invalid argument

# echo $?
1

# virsh memtune vm1
hard_limit     : 103000000004 kB
soft_limit     : 103100000004 kB
swap_hard_limit: 103100000004 kB

-> here soft-limit and swap-hard-limit change, but hard-limit not changes, and throw an error

# virsh memtune vm1 --hard-limit 103100000001 --soft-limit 103100000001 --swap-hard-limit 103100000001

# echo $?
0
# virsh memtune vm1
hard_limit     : 103100000004 kB
soft_limit     : 103100000004 kB
swap_hard_limit: 103100000004 kB
-> here all 3 values are changed, return correct
  
Actual results:
See step 3.

Expected results:
The results should be the same in step 3.

Additional info:
Comment 3 EricLee 2012-03-26 09:47:18 UTC 
Has same result as the description in the versions:
qemu-kvm-0.12.1.2-2.248.el6.x86_64
libvirt-0.9.10-6.el6.x86_64
kernel-2.6.32-251.el6.x86_64
Comment 4 Martin Kletzander 2012-05-31 07:46:16 UTC 
I was able to reproduce the bug on latest libvirt and qemu with 3.4.0 kernel. According to the logs, however, libvirt is doing everything correctly. Researching a little bit more, I came to a point where I am able to reproduce this bug *without* libvirt, causing the same error messages to appear from kernel. There is a workaround for this problem, but it doesn't seem right, because I've found out no information about it.

Let me explain. This is how to reproduce the bug without libvirt (numbers are taken from libvirt log after reproducing this according to the comment #1, so multiplied by 1024):

1) Start by creating a group for the actual process:
# mkdir /sys/fs/cgroup/memory/test
# echo $$ >/sys/fs/cgroup/memory/test/tasks 

2) Set the first round of parameters:
# echo 105472000001024 > /sys/fs/cgroup/memory/test/memory.limit_in_bytes
# echo 105472000001024 > /sys/fs/cgroup/memory/test/memory.soft_limit_in_bytes 
# echo 105472000001024 > /sys/fs/cgroup/memory/test/memory.memsw.limit_in_bytes 

3) Set the second round of parameters:
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.soft_limit_in_bytes 
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.limit_in_bytes 
-su: echo: write error: Invalid argument
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.memsw.limit_in_bytes 

4) Try the second round again:
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.soft_limit_in_bytes 
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.limit_in_bytes 
# echo 105574400001024 > /sys/fs/cgroup/memory/test/memory.memsw.limit_in_bytes 

Note that the second command from point 3) will fail until the memsw limit is greater or equal to the number we want to set. The workaround would then be, to set the memsw first and continue with the others. The problem is that this is  mentioned nowhere in the documentation and thus it looks like a bug.

Having memsw lower than the hard limit on memory is, of course, nonsense. But if this is a valid restriction, it should be mentioned in the documentation. If this is a bug, then it should be fixed (not having these restrictions would ease the setting from scripts and programs, because now there needs to be bunch of checks before the setting).

I'll clone this bug for kernel, to make this resolved asap.
Comment 6 Martin Kletzander 2012-07-02 10:16:23 UTC 
*** Bug 829241 has been marked as a duplicate of this bug. ***
Comment 7 Dave Allan 2012-07-23 13:42:56 UTC 

*** This bug has been marked as a duplicate of bug 839537 ***
Note You need to log in before you can comment on or make changes to this bug.