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 609016 - incorrect committed memory on idle host
Summary: incorrect committed memory on idle host
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Dan Kenigsberg
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 580954 634249
TreeView+ depends on / blocked
 
Reported: 2010-06-29 08:15 UTC by lihuang
Modified: 2013-01-11 03:05 UTC (History)
14 users (show)

Fixed In Version: qemu-kvm-0.12.1.2-2.116.el6
Doc Type: Bug Fix
Doc Text:
Due to error in the committed_memory() function, the ksmtuned service was unable to determine the correct amount of memory used by qemu-kvm processes when no such process existed. This has been fixed, the relevant part of the source code has been corrected to return 0 when no qemu-kvm process is found, and ksmtuned now works as expected.
Clone Of:
Environment:
Last Closed: 2011-05-19 11:32:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
calculate committed_memory with no qemus (853 bytes, patch)
2010-08-26 08:22 UTC, Dan Kenigsberg 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0534 0 normal SHIPPED_LIVE Important: qemu-kvm security, bug fix, and enhancement update 2011-05-19 11:20:36 UTC

Description lihuang 2010-06-29 08:15:46 UTC 
Description of problem:
there is a idle host,no qemu-kvm, no memery overcommit. 
but ksm scan is not stop .


[root@t78 ksm]# uptime 
 02:30:19 up  1:49,  4 users,  load average: 0.00, 0.00, 0.00
[root@t78 ksm]# free -m
             total       used       free     shared    buffers     cached
Mem:          7856        756       7099          0         50        212
-/+ buffers/cache:        493       7362
Swap:        10047          0      10047


[root@t78 ksm]# cat /sys/kernel/mm/ksm/run 
1
[root@t78 ksm]# cat /sys/kernel/mm/ksm/sleep_millisecs 
20
[root@t78 ksm]# cat /sys/kernel/mm/ksm/pages_to_scan 
64

[root@t78 ksm]# ps -aef | grep qemu
root     12118  2976  0 02:36 pts/0    00:00:00 grep qemu


from log /var/log/ksmtuned,the committed memory size is up to 9G.

Tue Jun 29 02:34:26 EDT 2010: committed 9100088 free 7537548
Tue Jun 29 02:34:26 EDT 2010: 10709059 > 8044856, start ksm
Tue Jun 29 02:34:26 EDT 2010: 7537548 > 1608971, decay
Tue Jun 29 02:34:26 EDT 2010: KSMCTL start 64 20
[root@t78 ksm]# date 
Tue Jun 29 02:34:59 EDT 2010

from /usr/sbin/ksmtuned. the committed memory is from "ps -o vsz"

committed_memory () {
    # calculate how much memory is committed to running qemu processes
    local progname
    progname=${1:-qemu}
    ps -o vsz `pgrep $progname` | awk '{ sum += $1 }; END { print sum }'
}


Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.82.el6.x86_64

How reproducible:
for the script it is 100%.but most of time ksm scan is stop because the committed memory size is not big enough

Steps to Reproduce:
1.start rhel6 host
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 RHEL Program Management 2010-06-29 08:42:54 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Dan Kenigsberg 2010-06-29 09:20:03 UTC 
I see that ksmtuned tuned ksm down to its minimum number of scanned pages per iteration (64). This is the intended feature; we do not want to turn ksm off completely, as the guest may start dirtying and clearing pages any minute.

Is there a real problem? How much cpu does ksm take from your machine?
top -p `pgrep ksmd`
Comment 4 lihuang 2010-06-29 09:50:32 UTC 
(In reply to comment #3)
> I see that ksmtuned tuned ksm down to its minimum number of scanned pages per
> iteration (64). This is the intended feature; we do not want to turn ksm off
> completely, as the guest may start dirtying and clearing pages any minute.
> 
from the script,if there is a qemu-kvm process running with low mem size. then ksm will stop.
So I got such a scenario :
boot  host -> ksm start
start vm   -> ksm top
quit  vm   -> ksm start
this is why created this BZ.

> Is there a real problem? How much cpu does ksm take from your machine?
> top -p `pgrep ksmd`    
yes, it is not a problem in cpu usage.
Comment 5 Dan Kenigsberg 2010-06-29 14:17:56 UTC 
(In reply to comment #4)
> from the script,if there is a qemu-kvm process running with low mem size. then
> ksm will stop.

No. When started, ksmtuned will never stop ksmd. It will only tune it very low. This was the intended behavior.

> So I got such a scenario :
> boot  host -> ksm start
> start vm   -> ksm top
> quit  vm   -> ksm start

Now I've lost you. After you stared a VM, ksm was stopped? How did this happen? Did you run `service ksmtuned retune`?
Comment 6 lihuang 2010-06-29 17:06:34 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > from the script,if there is a qemu-kvm process running with low mem size. then
> > ksm will stop.
> 
> No. When started, ksmtuned will never stop ksmd. It will only tune it very low.
> This was the intended behavior.
> 
seems ksmturned behavior differently ...please check following log.

> > So I got such a scenario :
> > boot  host -> ksm start
> > start vm   -> ksm top
> > quit  vm   -> ksm start
> 
> Now I've lost you. After you stared a VM, ksm was stopped? How did this happen?
> Did you run `service ksmtuned retune`?    


the scenario i got is as following,

Tue Jun 29 11:21:52 EDT 2010: committed 7975364 free 7525744
                                        ^^^^^^^
                                        boot host,no qemu-kvm process. so the committed mem size is from " ps -o vsz ",no idea why it is so high.
Tue Jun 29 11:21:52 EDT 2010: 9584335 > 8044856, start ksm
Tue Jun 29 11:21:52 EDT 2010: 7525744 > 1608971, decay
Tue Jun 29 11:21:52 EDT 2010: KSMCTL start 64 20

Tue Jun 29 11:22:52 EDT 2010: committed 2454768 free 6378492
                                        ^^^^^^^^
                                        start vm with 2G ram. so the committed mem size if from "ps -o vsz $pid_of_qemu-kvm"
Tue Jun 29 11:22:52 EDT 2010: 4063739 < 8044856 and free > 1608971, stop ksm
...
Tue Jun 29 11:35:53 EDT 2010: committed 2454692 free 6378100
Tue Jun 29 11:35:53 EDT 2010: 4063663 < 8044856 and free > 1608971, stop ksm

Tue Jun 29 11:36:53 EDT 2010: committed 9264764 free 7474880
                                        ^^^^^^^
                                        after stop guest.
Tue Jun 29 11:36:53 EDT 2010: 10873735 > 8044856, start ksm
Tue Jun 29 11:36:53 EDT 2010: 7474880 > 1608971, decay
Tue Jun 29 11:36:53 EDT 2010: KSMCTL start 64 20(In reply to comment #5)
Comment 7 RHEL Program Management 2010-07-15 14:06:42 UTC 
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 8 Dan Kenigsberg 2010-08-17 08:12:05 UTC 
Did you remember to run
  service ksmtuned retune
after qemu is started/stopped? I have no other guess why the logged committed memory is wrong.

(sorry for the late response, I probably lost the notification email)
Comment 12 Dan Kenigsberg 2010-08-26 08:22:42 UTC 
Created attachment 441139 [details]
calculate committed_memory with no qemus

Only now do I get your point. Sorry for being a bit thick. Would the attached patch solve the issue?
Comment 15 lihuang 2010-08-30 02:38:32 UTC 
(In reply to comment #12)
> Created attachment 441139 [details]
> calculate committed_memory with no qemus
> 
> Only now do I get your point. Sorry for being a bit thick. Would the attached
> patch solve the issue?

yes . works for me 
Sun Aug 29 22:37:53 EDT 2010: committed 0 free 7509288
Sun Aug 29 22:37:53 EDT 2010: 1612176 < 8060880 and free > 1612176, stop ksm
Comment 21 Keqin Hong 2010-10-15 10:35:05 UTC 
Verified on qemu-kvm-0.12.1.2-2.116.el6. PASS

(no committed memory on idle host)
Steps:
1. edit /etc/ksmtuned.conf
# uncomment the following if you want ksmtuned debug info
 LOGFILE=/var/log/ksmtuned
 DEBUG=1
2. reboot host (or #service ksmtuned restart)
3. check "committed memory" at /var/log/ksmtuned
Comment 22 Oliver Henshaw 2010-10-16 17:00:47 UTC 
In this patch you replace vsz by rsz. Was this intended?

I mean, it certainly seem to make more sense to use resident size than virtual size but I'm not sure that this change was deliberate - this bug isn't directly about use of vsz and the commit message http://gitorious.org/ksm-control-scripts/ksm-control-scripts/commit/1305fcb6bb2cfc0d86b3d5faed2056cca4c31164 doesn't mention it.
Comment 23 Jaromir Hradilek 2010-10-27 13:53:11 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Due to error in the committed_memory() function, the ksmtuned service was unable to determine the correct amount of memory used by qemu-kvm processes when no such process existed. This has been fixed, the relevant part of the source code has been corrected to return 0 when no qemu-kvm process is found, and ksmtuned now works as expected.
Comment 25 Keqin Hong 2011-01-12 09:02:47 UTC 
Re-verified on qemu-kvm-0.12.1.2-2.129.el6.x86_64, using steps mentioned in Comment 21. PASS
Comment 26 errata-xmlrpc 2011-05-19 11:32:06 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html
Comment 27 errata-xmlrpc 2011-05-19 12:46:13 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html
Note You need to log in before you can comment on or make changes to this bug.