Markus, thanks for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, we're not able to  guarantee the timeliness or suitability of a resolution for issues entered here because this is not a mechanism for requesting support.

If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution.

For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto

The "set_process_name" option in /etc/libvirt/qemu.conf sets "driver->setProcessName" and makes RHEL-6 libvirtd (qemuBuildCommandLine(), [src/qemu/qemu_command.c]) take the according branch:

    if (qemuCapsGet(qemuCaps, QEMU_CAPS_NAME)) {
        virCommandAddArg(cmd, "-name");
        if (driver->setProcessName &&
            qemuCapsGet(qemuCaps, QEMU_CAPS_NAME_PROCESS)) {
            virCommandAddArgFormat(cmd, "%s,process=qemu:%s",
                                   def->name, def->name);
        } else {
            virCommandAddArg(cmd, def->name);
        }
    }

# If enabled, libvirt will have QEMU set its process name to
# "qemu:VM_NAME", where VM_NAME is the name of the VM. The QEMU
# process will appear as "qemu:VM_NAME" in process listings and
# other system monitoring tools. By default, QEMU does not set
# its process title, so the complete QEMU command (emulator and
# its arguments) appear in process listings.
#
#set_process_name = 1

In qemu-kvm the "process=qemu:XXXX" part (actually, the XXXX part) is handled by

main() [vl.c]
  set_proc_name()
    prctl(PR_SET_NAME)

The name settable with this prctl is 16 chars long, of which "qemu:" takes up five.

(See "include/linux/sched.h" in the kernel:

/* Task command name length */
#define TASK_COMM_LEN 16

struct task_struct {
	/* ... */
	char comm[TASK_COMM_LEN]; /* executable name excluding path
				     - access with [gs]et_task_comm (which lock
				       it with task_lock())
				     - initialized normally by setup_new_exec */
	/* ... */
}

PR_SET_NAME [kernel/sys.c] invokes set_task_comm().)

Since libvirt always sets the "qemu:" prefix in the task name, I propose to keep the name based search in qemu-kvm's "redhat/ksmtuned", function committed_memory(), for stability's sake, as opposed to the uid-based search suggested in comment 0. (Of course Dan or Dan or Eric could know better, which is why I've CC'd them.) For searching we should use "pgrep" (from the same procps package as "ps"):

local pidlist
pidlist=$(pgrep -d ' ' -- '^qemu(-kvm|:.{1,11})$')

ps -p "$pidlist" -o rsz= | awk ...

(The XXXX part should be at least 1 char long; I think libvirtd doesn't allow def->name to be empty.)

(In reply to comment #0)

> there is also a minor bug
> @@ -99,7 +99,7 @@
>      debug committed $committed free $free
>      if [ $[committed + thres] -lt $total -a $free -gt $thres ]; then
>          KSMCTL stop
> -        debug "$[committed + thres] < $total and free > $thres, stop ksm"
> +        debug "$[committed + thres] < $total and $free > $thres, stop ksm"
>          return 1
>      fi
>      debug "$[committed + thres] > $total, start ksm"

I don't think this part is a bug. $free (ie. the decimal value) is logged just before the "if", the "free > $thres" part even seems more informative (it explains the logic, and the value is known from the previous log entry).

Created attachment 737309 [details]
ksmtuned: more flexible process name search pattern

*** Bug 963256 has been marked as a duplicate of this bug. ***

Verified on qemu-kvm-0.12.1.2-2.376.el6.x86_64:

1. in /etc/libvirt/qemu.conf: set_process_name = 1

2. start a guest consuming most memory of host:

# free -m
             total       used       free     shared    buffers     cached
Mem:          7697       7526        170          0          8       1272
-/+ buffers/cache:       6245       1451
Swap:        57343          6      57337

3.# ps -C "qemu:vr-rhel6-x86_64-kvm" -o comm
COMMAND
qemu:vr-rhel6-x

4.#cat /var/log/ksmtuned

Thu Jul  4 19:18:14 CST 2013: committed 55816 free 7574688
Thu Jul  4 19:18:14 CST 2013: 1632272 < 7882284 and free > 1576456, stop ksm
Thu Jul  4 19:19:14 CST 2013: committed 6123360 free 1484712
Thu Jul  4 19:19:14 CST 2013: 7699816 > 7882284, start ksm
Thu Jul  4 19:19:14 CST 2013: 1484712 < 1576456, boost
Thu Jul  4 19:19:14 CST 2013: KSMCTL start 600 21

Reproduced with qemu-kvm-0.12.1.2-2.356.el6.x86_64:


# free -m
             total       used       free     shared    buffers     cached
Mem:          7697       5720       1976          0          6         47
-/+ buffers/cache:       5666       2030
Swap:        57343        147      57196


#cat /var/log/ksmtuned

Fri Jul  5 11:02:50 CST 2013: committed 1262132 free 2086504
Fri Jul  5 11:02:50 CST 2013: 2838588 < 7882284 and free > 1576456, stop ksm
Fri Jul  5 11:03:50 CST 2013: committed 1262228 free 2073532
Fri Jul  5 11:03:50 CST 2013: 2838684 < 7882284 and free > 1576456, stop ksm


The guest takes 4.5G memory, bug it only counts 1262228.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1553.html