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=-6.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 58EE5C07E85 for ; Tue, 11 Dec 2018 11:06:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A35F20811 for ; Tue, 11 Dec 2018 11:06:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A35F20811 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726312AbeLKLG5 (ORCPT ); Tue, 11 Dec 2018 06:06:57 -0500 Received: from ozlabs.org ([203.11.71.1]:57223 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726117AbeLKLG5 (ORCPT ); Tue, 11 Dec 2018 06:06:57 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43Dcb21q6Qz9s3Z; Tue, 11 Dec 2018 22:06:53 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Andrew Murray 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" Subject: Re: [PATCH 10/10] perf/doc: update design.txt for exclude_{host|guest} flags In-Reply-To: <20181120133202.GH35798@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> Date: Tue, 11 Dec 2018 22:06:53 +1100 Message-ID: <87bm5sxqya.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ 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? And I don't see any x86 code using exclude_hv. But maybe that's OK, I just worry this is confusing for users. cheers