From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels Date: Tue, 22 May 2012 22:46:07 +0200 Message-ID: <4FBBFB0F.5070601@amd.com> References: <4FBBB9AF.6020704@amd.com> <4FBBC44B.9020007@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FBBC44B.9020007@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jeremy Fitzhardinge Cc: xen-devel , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 05/22/2012 06:52 PM, Jeremy Fitzhardinge wrote: > On 05/22/2012 09:07 AM, Andre Przywara wrote: >> Hi, >> >> while testing some APERF/MPERF semantics I discovered that this >> feature is enabled in Xen Dom0, but is not reliable. >> The Linux kernel's scheduler uses this feature if it sees the CPUID >> bit, leading to costly RDMSR traps (a few 100,000s during a kernel >> compile) and bogus values due to VCPU migration during the measurement. >> The attached patch explicitly disables this CPU capability inside the >> Linux kernel, I couldn't measure any APERF/MPERF reads anymore with >> the patch applied. >> I am not sure if the PVOPS code is the right place to fix this, we >> could as well do it in the HV's xen/arch/x86/traps.c:pv_cpuid(). >> Also when the Dom0 VCPUs are pinned, we could allow this, but I am not >> sure if it's worth to do so. > > Seems reasonable to me. Do all those RDMSR traps have a measurable > performance effect? I haven't tested this. I was more concerned about the invalid readouts from the MSRs from Dom0 side. One of our tests complained that the second of two consecutive APERF reads was actually lower than the first, violating the strict monotony requirement. Even if these negative values would be rare, I assume the differences are somewhat random if the readouts happen to come from different pCPUs. Start "watch cpupower monitor" and compile a kernel in Dom0 to see what I mean... > > Also, is there a symbolic constant for that bit? APERFMPERF is one of the scattered bits (arch/x86/kernel/cpu/scattered.c), so the existing constant uses the artificial Linux numbering. But right, for the next version I'd create a symbolic constant. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712