Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2136879pxb; Thu, 4 Nov 2021 14:41:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEk2WxwMDLiERwmnLmwuXmVO3WXoFOKzYCxtVeVXXmNSVOHwJwcEYDUr4GBU50VWtldS+c X-Received: by 2002:a50:9b06:: with SMTP id o6mr71829791edi.284.1636062061228; Thu, 04 Nov 2021 14:41:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636062061; cv=none; d=google.com; s=arc-20160816; b=y4HFp2wbQYbglKkVyxV65QTJX1YadFLhvbRza6tjlO4p4xH1fQx8ZQwDlV9pzXx3QZ dAjsWZDGVXxvjdGX7FVhkNsTjQbXHzXNxx1Japsmqqq6fRFGhlowChnesKNylAZ9Q6Qd nVjOSObUlwsQNFZAL9MuLcFtkwAye0/i4Vjh3vfLR9vHv30jdQl8ynOWsBg7ILN+foqn EkYJ6/cMk4dOL6ovUS6qaJmuW0Ga7QAO60CJKMn/Thvn5CpGKOiVd9PMihE/FdU37hku C11yftbseOca0HZ97d3kQ/w3AuCnWiUu5dBqBsqpTO1qNW6+AeTUvlCSqdJ+xYLFdB2z DTcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=t33HpEEnk1etvqqIlmlIbAYJ4j6h+BHbpRH2GGqHboQ=; b=krr15qS+Rz39v7c4tUJuMzXamr5WX7ani1xb0vLmV2m82bO0ZFiRrDizc28fN6xdQs ywnJlqxXHvTYFTcP+nHSrzHQSeZDK8wYPdL2ohRhQY8Id0tqmAUYWtBm9msW9gqyZTej uXVzOYaHn8I62+KOSaddfCPHTk1Nl1c2obc3QjareWSWxkC3aj2Ol+S6mShpp2ctwbVJ 3jfmtCELXZ7wmneDv4dHSFOqvadwvZx1RLFOfctXc7I9VkToBcUNIrQYq3sqk7AI0ZDw 516jMuSKkaCjFG8G/NvKw3aM5vXuiKMXIEqqOmfRFNHkfnuxZjo5dnBXnHnMPiiQarf3 f7oQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sd21si12367589ejc.727.2021.11.04.14.40.37; Thu, 04 Nov 2021 14:41:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232119AbhKDVlb (ORCPT + 99 others); Thu, 4 Nov 2021 17:41:31 -0400 Received: from mail-lj1-f182.google.com ([209.85.208.182]:38846 "EHLO mail-lj1-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231142AbhKDVla (ORCPT ); Thu, 4 Nov 2021 17:41:30 -0400 Received: by mail-lj1-f182.google.com with SMTP id v23so11786978ljk.5 for ; Thu, 04 Nov 2021 14:38:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t33HpEEnk1etvqqIlmlIbAYJ4j6h+BHbpRH2GGqHboQ=; b=LKdQBFzsTeqe7e8rEYbE9xyQ7zF4P8Kzo5/Ws3tk/QeOC2qvaaMJ3sMMIqaIn2WNvh X4J4TsnUxm5QvW8/RVq8Qdqc5WGjgV8y5mnZAryePQsRqKAnPmIgLA8p6DH3f2YXGrtX ueFX8dis8MCGDwxQrkfjY6DZrMMZTaiYPSpft1C89eekojAIcnjETcc+1OsJ28z/KjK6 HwivEm3CAa3niA8Io6v8S4CI51cdIpBVqtNZ8h22afWOkWFpXSzNNnW4d++WTMAkywNk Z5o0pzF5H9oDleIk7g+87079OKV8OhDlbgPGfkNQIFuUbBjWYeacFJgFgnehWHVXmhmr 9Ueg== X-Gm-Message-State: AOAM5311ObdTchQAh2GmPYVPi9DHTCDzydb6MnXwqIgZWfFjpzN31EJ/ MJhtroUICo3ulOyr7Xl97akyhlRRHNoDB4TGMb0= X-Received: by 2002:a2e:8841:: with SMTP id z1mr55299282ljj.180.1636061930567; Thu, 04 Nov 2021 14:38:50 -0700 (PDT) MIME-Version: 1.0 References: <20211029224929.379505-1-namhyung@kernel.org> In-Reply-To: From: Namhyung Kim Date: Thu, 4 Nov 2021 14:38:39 -0700 Message-ID: Subject: Re: [PATCH v3] perf evsel: Fix missing exclude_{host,guest} setting To: Arnaldo Carvalho de Melo Cc: Stephane Eranian , Jiri Olsa , Ingo Molnar , Peter Zijlstra , LKML , Andi Kleen , Ian Rogers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 4, 2021 at 10:40 AM Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 03, 2021 at 03:29:50PM -0700, Stephane Eranian escreveu: > > On Wed, Nov 3, 2021 at 2:03 PM Arnaldo Carvalho de Melo wrote: > > > Em Wed, Nov 03, 2021 at 10:35:04AM -0700, Stephane Eranian escreveu: > > > > On Wed, Nov 3, 2021 at 4:32 AM Arnaldo Carvalho de Melo wrote: > > > > > Em Wed, Nov 03, 2021 at 12:44:12AM -0700, Stephane Eranian escreveu: > > > > > > On Wed, Nov 3, 2021 at 12:24 AM Jiri Olsa wrote: > > > > > > > > If the pmu doesn't support host/guest filtering, pmu/bla1/G > > > > > > > > may count something. Not sure if it's better to error out. > > > > > > > > But the cycles:G and instructions:G should result in 0 > > > > > > > > in case there's no VM running. > > > > > > > > hm, I think if pmu doesn't support host/guest filtering then > > > > > > > I think 'pmu/bla1/G' should error, no? better no number than > > > > > > > bad number > > > > > > > Yes, it should in my opinion. > > > > > > Yeah, I thought about this yesterday (holiday here). > > > > > Otherwise you create the illusion that you are monitoring in guest > > > > mode when you are not. > > > > > The question is: how can the tool know which modifiers are supported > > > > per pmu model? > > > > As things stand kernel-wise, we should just do capability querying, i.e. > > > if the user asks for a feature not available for a specific PMU, we > > > should refuse and provide a helpful error message to the user. > > > > If the PMUs in the kernel had some kind of mask that stated what of the > > > 'struct perf_event_attr' selectable features are supported, then we > > > would just be able to avoid bothering the kernel asking for unsupported > > > stuff. > > > I think we could add something like that in the sysfs entry for each > > PMU instance. > > that would avoid all these perf_event_open() calls and trying to > > decipher the error > > code. > > That would speed up these checks with newer kernels, yeah, with older > kernels we'd fall back to what we have now + bailing out in the current > case (PMUs not supporting exclude_guest). Agreed. > > > > Just for exclude_guest we don't even need to have > > > evsel->pmu->missing_features.exclude_guest, as this is a hard error, no > > > point in caching previous capability queries. But we set attr.exclude_guest by default so we should check if the user set the modifier explicitly or not. With the explicit G modifier, it should fail immediately. If it's implicit, then we should remove it from the attr and proceed. So it's worth it to cache the result. I think we don't need to fill evsel->pmu link unnecessarily. I mean we can set it only if needed (for exclude_guest) and keep a NULL pointer when it has no problem. Thanks, Namhyung