Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp714641imu; Tue, 11 Dec 2018 06:30:10 -0800 (PST) X-Google-Smtp-Source: AFSGD/UTIvvFikNOJHVVagm5RtLyTk1BhH9mfcqFVxVJ1p0A1TaTCHHKljUfpF6CIuxv2NEUtoU6 X-Received: by 2002:a62:42d4:: with SMTP id h81mr16476286pfd.259.1544538610880; Tue, 11 Dec 2018 06:30:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544538610; cv=none; d=google.com; s=arc-20160816; b=0PHy/ETmuaQh2XXArXPk9wdZFhg8EA3tAMNzB/HF2yvvZZaOi9CjOSNF/pgxDrJ3ZQ hLLk03XcCmZyT0YCPkcR6pB3zcOvfuP6gtW1J96/aNd/Eg3yWqu+exHQBz46ES1AcmNP M1eOfOjjQzn9XeFlY1DFRdjNfLpzONYwHu3e8Xo/X8uv0dr8ofb/WBciofY6fENRIS/n m2lA4MVdeNsWqA+3lkUOXN0+nySYZK/kUI4mU2690rRD4MnM5szPcHhaOtfSt5Vf9ae4 NStzyR9Is6SuJ94D+Iy1gSZJlrDyxTjgynhKRMQf1RCG/0gi5mgG5VKIveM0GlAdtcNw f6LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xdmE3pgFmdEzD/zZLy+W0fCoSKG//XaSyke7eg77RME=; b=G4LlWJAix7t/8FhW2J9YaYkVBAzzhetiOsvV2LlpSXF+X5m69vXwO3p/PbZMxx80Jn hRHSiYEnJcqq7bO07jhWosWCwqA3ml+8vc66fsm45nf4UJHWQiUb0cMtLNUPwpooBAxK ZXQQo0ecVc9HCW4Fmu5d8n5sCrOJN2Du13gM0eqOxINz+8VdCM2IgkL8HHfr7lgRSX6O IL3R+kDw7ozGl8nr2N6O0Gv4OK6b0TP9XMrdeFb2WUMGwHoUJEHYq1zF7JToEPo4cZd2 sgdEndS6LCEW1NSBKJfOuFNJlmcShUgoppdvy6rl26xQgOQYqwN87Tswc5jAGR01DCJ4 Jkzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4si12919228pff.161.2018.12.11.06.29.37; Tue, 11 Dec 2018 06:30:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726669AbeLKN7I (ORCPT + 99 others); Tue, 11 Dec 2018 08:59:08 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:47876 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726286AbeLKN7H (ORCPT ); Tue, 11 Dec 2018 08:59:07 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 072651596; Tue, 11 Dec 2018 05:59:07 -0800 (PST) Received: from localhost (unknown [10.37.6.11]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F8CD3F59C; Tue, 11 Dec 2018 05:59:06 -0800 (PST) Date: Tue, 11 Dec 2018 13:59:03 +0000 From: Andrew Murray To: Michael Ellerman Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Shawn Guo , Sascha Hauer , Will Deacon , Mark Rutland , Benjamin Herrenschmidt , Thomas Gleixner , Borislav Petkov , x86@kernel.org, linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joerg Roedel , "paulus@samba.org" , Christoffer.Dall@arm.com Subject: Re: [PATCH 10/10] perf/doc: update design.txt for exclude_{host|guest} flags Message-ID: <20181211135903.GG13393@e119886-lin.cambridge.arm.com> References: <1542363853-13849-1-git-send-email-andrew.murray@arm.com> <1542363853-13849-11-git-send-email-andrew.murray@arm.com> <87pnv00yuf.fsf@concordia.ellerman.id.au> <20181120133202.GH35798@e119886-lin.cambridge.arm.com> <87bm5sxqya.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bm5sxqya.fsf@concordia.ellerman.id.au> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 11, 2018 at 10:06:53PM +1100, Michael Ellerman wrote: > [ Reviving old thread. ] > > Andrew Murray writes: > > On Tue, Nov 20, 2018 at 10:31:36PM +1100, Michael Ellerman wrote: > >> Andrew Murray writes: > >> > >> > Update design.txt to reflect the presence of the exclude_host > >> > and exclude_guest perf flags. > >> > > >> > Signed-off-by: Andrew Murray > >> > --- > >> > tools/perf/design.txt | 4 ++++ > >> > 1 file changed, 4 insertions(+) > >> > > >> > diff --git a/tools/perf/design.txt b/tools/perf/design.txt > >> > index a28dca2..7de7d83 100644 > >> > --- a/tools/perf/design.txt > >> > +++ b/tools/perf/design.txt > >> > @@ -222,6 +222,10 @@ The 'exclude_user', 'exclude_kernel' and 'exclude_hv' bits provide a > >> > way to request that counting of events be restricted to times when the > >> > CPU is in user, kernel and/or hypervisor mode. > >> > > >> > +Furthermore the 'exclude_host' and 'exclude_guest' bits provide a way > >> > +to request counting of events restricted to guest and host contexts when > >> > +using virtualisation. > >> > >> How does exclude_host differ from exclude_hv ? > > > > I believe exclude_host / exclude_guest are intented to distinguish > > between host and guest in the hosted hypervisor context (KVM). > > OK yeah, from the perf-list man page: > > u - user-space counting > k - kernel counting > h - hypervisor counting > I - non idle counting > G - guest counting (in KVM guests) > H - host counting (not in KVM guests) > > > Whereas exclude_hv allows to distinguish between guest and > > hypervisor in the bare-metal type hypervisors. > > Except that's exactly not how we use them on powerpc :) > > We use exclude_hv to exclude "the hypervisor", regardless of whether > it's KVM or PowerVM (which is a bare-metal hypervisor). > > We don't use exclude_host / exclude_guest at all, which I guess is a > bug, except I didn't know they existed until this thread. > > eg, in a KVM guest: > > $ perf record -e cycles:G /bin/bash -c "for i in {0..100000}; do :;done" > $ perf report -D | grep -Fc "dso: [hypervisor]" > 16 > > > > In the case of arm64 - if VHE extensions are present then the host > > kernel will run at a higher privilege to the guest kernel, in which > > case there is no distinction between hypervisor and host so we ignore > > exclude_hv. But where VHE extensions are not present then the host > > kernel runs at the same privilege level as the guest and we use a > > higher privilege level to switch between them - in this case we can > > use exclude_hv to discount that hypervisor role of switching between > > guests. > > I couldn't find any arm64 perf code using exclude_host/guest at all? Correct - but this is in flight as I am currently adding support for this see [1]. > > And I don't see any x86 code using exclude_hv. I can't find any either. > > But maybe that's OK, I just worry this is confusing for users. There is some extra context regarding this where exclude_guest/exclude_host was added, see [2] and where exclude_hv was added, see [3] Generally it seems that exclude_guest/exclude_host relies upon switching counters off/on on guest/host switch code (which works well in the nested virt case). Whereas exclude_hv tends to rely solely on hardware capability based on privilege level (which works well in the bare metal case where the guest doesn't run at same privilege as the host). I think from the user perspective exclude_hv allows you to see your overhead if you are a guest (i.e. work done by bare metal hypervisor associated with you as the guest). Whereas exclude_guest/exclude_host doesn't allow you to see events above you (i.e. the kernel hypervisor) if you are the guest... At least that's how I read this, I've copied in others that may provide more authoritative feedback. [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2018-December/033698.html [2] https://www.spinics.net/lists/kvm/msg53996.html [3] https://lore.kernel.org/patchwork/patch/143918/ Thanks, Andrew Murray > > cheers