From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CE6BC48BDF for ; Tue, 15 Jun 2021 17:06:03 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D07E561883 for ; Tue, 15 Jun 2021 17:06:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D07E561883 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5C2254A4BE; Tue, 15 Jun 2021 13:06:02 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mef+4qEvowy; Tue, 15 Jun 2021 13:06:00 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 178334A4FC; Tue, 15 Jun 2021 13:06:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1063E4A4FC for ; Tue, 15 Jun 2021 13:05:59 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0usn8cPSPGpg for ; Tue, 15 Jun 2021 13:05:57 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C5CE44A4BE for ; Tue, 15 Jun 2021 13:05:57 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 409CF6187E; Tue, 15 Jun 2021 17:05:55 +0000 (UTC) Received: from [185.219.108.64] (helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ltCVd-007kk5-8L; Tue, 15 Jun 2021 18:05:53 +0100 Date: Tue, 15 Jun 2021 18:05:52 +0100 Message-ID: <87lf7bhxcf.wl-maz@kernel.org> From: Marc Zyngier To: Aman Priyadarshi Subject: Re: KVM: arm64: pmu: Reset sample period on overflow handling In-Reply-To: <322843db2f986f418d4175ca9c10e0904aa81d7a.camel@amazon.de> References: <322843db2f986f418d4175ca9c10e0904aa81d7a.camel@amazon.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: apeureka@amazon.de, kvmarm@lists.cs.columbia.edu, graf@amazon.com, alisaidi@amazon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Alexander Graf , kvmarm@lists.cs.columbia.edu, Ali Saidi X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Aman, [- Andrew] On Tue, 15 Jun 2021 16:15:28 +0100, Aman Priyadarshi wrote: > > Hey, > > I have been chasing down a regression on guest side related to pmu cycle > counters, and I found that reverting these two patches help: > > - 30d97754b2d1 ("KVM: arm/arm64: Re-create event when setting counter > value") > - 8c3252c06516 ("KVM: arm64: pmu: Reset sample period on overflow > handling") > > However, I do not yet fully understand the underlying problem. > > Regression can be reproduced by running simple userspace processes > consuming 100% of cpus and checking the number of pmu cycles. > > ``` > $ cat foo.c > #include > > int main() > { > while (1) ; > return 0; > } > > > $ gcc -o foo foo.c > $ for x in {0..63}; do ./foo & done > $ sudo perf stat -A -a -e cpu-clock:pppH,cycles -- sleep 10 > CPU0 22,397,323,233 cycles # 2.240 GHz > CPU1 6,444,741,327 cycles # 0.644 GHz > CPU2 17,029,444,425 cycles # 1.703 GHz > CPU3 4,298,054,663 cycles # 0.430 GHz > CPU4 6,444,769,216 cycles # 0.644 GHz > CPU5 6,045,456,891 cycles # 0.605 GHz > CPU6 4,298,204,814 cycles # 0.430 GHz > CPU7 6,444,346,686 cycles # 0.644 GHz > CPU8 4,298,012,726 cycles # 0.430 GHz > CPU9 6,445,547,392 cycles # 0.645 GHz > CPU10 4,297,996,144 cycles # 0.430 GHz > ... > ``` > > Expected behavior is to have all cores around 2.5GHz on all CPUs given that > all CPUs are 100% in the guest. > > The nonsensical values reported by the pmu counters is only observed on > certain combination of host and guest kernel. > > I was able to reproduce it on v5.4.34 and v5.13.0-rc5 running on the host > side, and 4.14.10 on the guest side. > > I am running Ubuntu 18.04 cloud image with 4.14.10 kernel headers > installed: > > https://cloud-images.ubuntu.com/releases/bionic/release/ubuntu-18.04-server-cloudimg-arm64.img > > Note, cloud image comes with 4.15.y kernel installed, which does not show > any regression. Can you reproduce the issue with vanilla guest kernels? It'd be interesting to understand what makes it work on the guest side. Can you please bisect it? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm