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-next>] [day] [month] [year] [list]
Message-ID: <55F9409B.9020501@de.ibm.com>
Date:	Wed, 16 Sep 2015 12:12:43 +0200
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Cc:	rkrcmar@...hat.com, David Hildenbrand <dahi@...ux.vnet.ibm.com>,
	David Matlack <dmatlack@...gle.com>,
	Jens Freimann <jfrei@...ux.vnet.ibm.com>
Subject: Re: [PATCH] KVM: add halt_attempted_poll to VCPU stats

Am 15.09.2015 um 18:27 schrieb Paolo Bonzini:
> This new statistic can help diagnosing VCPUs that, for any reason,
> trigger bad behavior of halt_poll_ns autotuning.
> 
> For example, say halt_poll_ns = 480000, and wakeups are spaced exactly
> like 479us, 481us, 479us, 481us. Then KVM always fails polling and wastes
> 10+20+40+80+160+320+480 = 1110 microseconds out of every
> 479+481+479+481+479+481+479 = 3359 microseconds. The VCPU then
> is consuming about 30% more CPU than it would use without
> polling.  This would show as an abnormally high number of
> attempted polling compared to the successful polls.
> 
> Cc: Christian Borntraeger <borntraeger@...ibm.com<
> Cc: David Matlack <dmatlack@...gle.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>

Acked-by: Christian Borntraeger <borntraeger@...ibm.com>

yes, this will help to detect some bad cases, but not all.

PS: 
upstream maintenance keeps me really busy at the moment :-)
I am looking into a case right now, where auto polling goes 
completely nuts on my system:

guest1: 8vcpus		guest2: 1 vcpu
iperf with 25 process (-P25) from guest1 to guest2.

I/O interrupts on s390 are floating (pending on all CPUs) so on 
ALL VCPUs that go to sleep, polling will consider any pending
network interrupt as successful poll. So with auto polling the
guest consumes up to 5 host CPUs without auto polling only 1.
Reducing  halt_poll_ns to 100000 seems to work (goes back to 
1 cpu).

The proper way might be to feedback the result of the
interrupt dequeue into the heuristics. Don't know yet how
to handle that properly.

Christian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ