linux-kernel - Re: doubled idle count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 07 Nov 2008 16:20:47 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: doubled idle count

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Ferenc Wagner wrote:
>
>> After upgrading a Xen virtual machine to Debian's 2.6.26-4 kernel, I
>> noticed that the idle counter doubled its pace on one of the machines:
>> [command line stuff elided, graph follows]
>
> So you're saying that they are identical Xen and guest kernel binaries,
> but one of three is showing doubled idle time?

I've affirmed this in detail on Sept 19.  Now I'm trying to resurrect
this thread, maybe some visual stimulation will help...


Download attachment "noc.niif.grid-cpu-week.png" of type "image/png" (24571 bytes)


Consider the above CPU graph (courtesy of Munin, tweaked to accept
values above 100%).  This virtual machine (Linux 2.6.26.6 + migration
patches from 2.6.27) can run on two identically configured hosts
running the 3.2.1 hypervisor and a Linux 2.6.18 dom0 kernel.

Nov 2 15:22 (rising edge): domU shut down and recreated with
    clocksource=jiffies.

Nov 3 16:01 (nothing to see): domU shut down again and recreated
    without specifying clocksource on the kernel command line.  It
    selected the xen clocksource.

Nov 6 17:22 (falling edge): domU live migrated to the other host.

So live migration alone shaked the idle figures back in shape.

I really wonder if anybody has some insight into this anomaly.  In
itself it isn't a problem, but I've got other issues (some timing
related, like serial overruns, and also some dom0 crashes), so I'd
like to get rid of anything suspicious.

Regards,
Feri.

xm info on the two dom0-s:

host                   : xen2-ha
release                : 2.6.18-6-xen-686
version                : #1 SMP Mon Oct 13 20:36:55 UTC 2008
machine                : i686
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 1
threads_per_core       : 2
cpu_mhz                : 3056
hw_caps                : bfebfbff:00000000:00000000:00000080:00004400
total_memory           : 3071
free_memory            : 2781
node_to_cpu            : node0:0-3
xen_major              : 3
xen_minor              : 2
xen_extra              : -1
xen_caps               : xen-3.0-x86_32p 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xf5800000
xen_changeset          : unavailable
cc_compiler            : gcc version 4.3.1 (Debian 4.3.1-2) 
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Sat Jun 28 15:25:00 UTC 2008
xend_config_format     : 4

domU config:

name = "noc.grid"
kernel = "/home/wferi/vmlinuz-2.6.26-1-686-bigmem"
ramdisk = "/home/wferi/initrd.img-2.6.26-1-686-bigmem"
memory = 512
vif = [ 'mac=00:16:3e:00:00:13, bridge=br894',
	'mac=00:16:3e:00:00:30, bridge=br897' ]
root = "/dev/mapper/noc-root ro"
extra = ""
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'