Received: by 2002:ab2:6309:0:b0:1fb:d597:ff75 with SMTP id s9csp258877lqt; Thu, 6 Jun 2024 02:43:36 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWmLK2dqVdLR4qFnF/7XV6+YctMZntZGT69T4tnmMY9ZyF79bdi2EEJCb63ImsgqD+4Bo/3ECYUhdnGjSwgLt+pnjDNe0eWOpVet//TuQ== X-Google-Smtp-Source: AGHT+IGrGLxiowwDQIy0vl/+AeRu2Diqv6FK9laGKKclyF1MlYLXe64OW3zzCkAmEAP62Bwq/0uZ X-Received: by 2002:a17:906:3854:b0:a68:fafc:659 with SMTP id a640c23a62f3a-a699faa624amr339203166b.29.1717667016266; Thu, 06 Jun 2024 02:43:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717667016; cv=pass; d=google.com; s=arc-20160816; b=WYDFvDW92llPdvWjHr57JBZE/UJLmx4V0MfuGnHKJhZUZUycqsGUzBBxoRitkkXEXY tV6caD+6KrvBY3QR7YGmw54xYacl/vz6zuRM51nMyN4HuvxI1Cnh21llyEN3ZI+bl9YF I8KIuJVjnhGQY37bjc0351/v4ous4+FFAje7SkcgRI5O9fjw7NNDjmZcDtCkatLZ+Her mio9HgJsCtKZR2Rbj48RBt9OVLb2YIfVay/6hJqE86sPnJ6ixOoWkUFBQ7+VWJcqyUyz maUlNeg4gF7ePfK8139P5/8gYH4OnZDKeA9vqZMkg0l3Qw0efzPGZ6nRPfcFzV+OQMr5 dPBQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=4Rmjl18naID9M3uhzox2RpOK+yVeBqWsN5eEaSlSQDc=; fh=Os2Z9h2nt2EIM3xyhmCKVBpw4VaU/AohD28GFbpv6Dw=; b=JwFQU4AY1huZETg8rEkPWbFYqOAR9kpZpmnAJzgaZXqyk7f+Pw2dr3X6T+nzhv7JNl X3MLmHtTvueIXFiyWQeyh8mhxqNFFVQwH1aNZXgV6LDIeumsCpWQh5UYvBgmWPWzsKSJ bae+mrlJd1yVtn1+gAFDbelwY9Bpz4m1uD+rUGAGcOn4zpf04nDGXUlLKVNAPzP4nPQy w5Bi/z9Q6RKqODIjrpUDRd4hOHXq4xj2SvM04p8r8CIotQj9RQ7Ef4escgk6uTsdReYJ WLtOLaravK2+PsUoIKf4I880VPvSnVQl8i9BkPWPaY9AgWTCpUKRppD4Jm39s33kGttg HSYA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-204036-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-204036-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a640c23a62f3a-a6c8074bb61si48779266b.1044.2024.06.06.02.43.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jun 2024 02:43:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-204036-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-204036-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-204036-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id B9E181F22456 for ; Thu, 6 Jun 2024 09:43:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ACC2013E3FF; Thu, 6 Jun 2024 09:42:39 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4F1A51527AA; Thu, 6 Jun 2024 09:42:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717666959; cv=none; b=faXbVG7Q+WipZPAtiKasMEBRo/hyKcvajYJaVGRQi8yiDOMOc74gQjOfEh6AOp8g63SXddIQK2GUXPUxcjV5UbeKyDlZfJcP/nTIo3bZQOItdNqC8UWJcl2q8nJa3JshfcyxEZgZ0hMgs6TLCvVo8ww4gTkBk8t59/B3mkJ4M8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717666959; c=relaxed/simple; bh=WfZOLSDl+Ni7nETLkrLA9ZjhM4icZcFITRF4meVlCdc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VD73ViVQBtYR+AMGbvm+EsVDTFnquNQ0bhV9MWck300GYMYHJdTkxuY+em1z9xbbWr58hpEuC7lbgq3TaA7avzOqXZ1NsQ9DMHeZSCFkuT4GOxFesknXaGnSeQoubjjXa+68W84lJev3zCcq3Y2i1zNq23iUZeUQnSDzTQ+zGto= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 17757339; Thu, 6 Jun 2024 02:43:01 -0700 (PDT) Received: from [192.168.1.100] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DB2743F762; Thu, 6 Jun 2024 02:42:34 -0700 (PDT) Message-ID: Date: Thu, 6 Jun 2024 10:42:33 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] perf evlist: Force adding default events only to core PMUs To: Namhyung Kim , Ian Rogers Cc: Arnaldo Carvalho de Melo , Leo Yan , Linus Torvalds , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , Kan Liang , Dominique Martinet , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org References: <20240527105842.GB33806@debian-dev> Content-Language: en-US From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/06/2024 08:09, Namhyung Kim wrote: > On Wed, Jun 5, 2024 at 4:02 PM Ian Rogers wrote: >> >> On Wed, Jun 5, 2024 at 1:29 PM Namhyung Kim wrote: >>> >>> On Thu, May 30, 2024 at 3:52 PM Namhyung Kim wrote: >>>> >>>> On Thu, May 30, 2024 at 06:46:08AM -0700, Ian Rogers wrote: >>>>> On Thu, May 30, 2024 at 5:48 AM James Clark wrote: >>>>>> >>>>>> On 30/05/2024 06:35, Namhyung Kim wrote: >>>>>>> It might not be a perfect solution but it could be a simple one. >>>>>>> Ideally I think it'd be nice if the kernel exports more information >>>>>>> about the PMUs like sampling and exclude capabilities. >>>>>>>> Thanks, >>>>>>> Namhyung >>>>>> >>>>>> That seems like a much better suggestion. Especially with the ever >>>>>> expanding retry/fallback mechanism that can never really take into >>>>>> account every combination of event attributes that can fail. >>>>> >>>>> I think this approach can work but we may break PMUs. >>>>> >>>>> Rather than use `is_core` on `struct pmu` we could have say a >>>>> `supports_sampling` and we pass to parse_events an option to exclude >>>>> any PMU that doesn't have that flag. Now obviously more than just core >>>>> PMUs support sampling. All software PMUs, tracepoints, probes. We have >>>>> an imprecise list of these in perf_pmu__is_software. So we can set >>>>> supports_sampling for perf_pmu__is_software and is_core. >>>> >>>> Yep, we can do that if the kernel provides the info. But before that >>>> I think it's practical to skip uncore PMUs and hope other PMUs don't >>>> have event aliases clashing with the legacy names. :) >>>> >>>>> >>>>> I think the problem comes for things like the AMD IBS PMUs, intel_bts >>>>> and intel_pt. Often these only support sampling but aren't core. There >>>>> may be IBM S390 PMUs or other vendor PMUs that are similar. If we can >>>>> make a list of all these PMU names then we can use that to set >>>>> supports_sampling and not break event parsing for these PMUs. >>>>> >>>>> The name list sounds somewhat impractical, let's say we lazily compute >>>>> the supports_sampling on a PMU. We need the sampling equivalent of >>>>> is_event_supported: >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/print-events.c?h=perf-tools-next#n242 >>>>> is_event_supported has had bugs, look at the exclude_guest workaround >>>>> for Apple PMUs. It also isn't clear to me how we choose the event >>>>> config that we're going to probe to determine whether sampling works. >>>>> The perf_event_open may reject the test because of a bad config and >>>>> not because sampling isn't supported. >>>>> >>>>> So I think we can make the approach work if we had either: >>>>> 1) a list of PMUs that support sampling, >>>>> 2) a reliable "is_sampling_supported" test. >>>>> >>>>> I'm not sure of the advantages of doing (2) rather than just creating >>>>> the set of evsels and ignoring those that fail to open. Ignoring >>>>> evsels that fail to open seems more unlikely to break anything as the >>>>> user is giving the events/config values for the PMUs they care about. >>>> >>>> Yep, that's also possible. I'm ok if you want to go that direction. >>> >>> Hmm.. I thought about this again. But it can be a problem if we ignore >>> any failures as it can be a real error due to other reason - e.g. not >>> supported configuration or other user mistakes. >> >> Right, we have two not good choices: >> >> 1) Try to detect whether sampling is supported, but any test doing >> this needs to guess at a configuration and we'll need to deflake this >> on off platforms like those that don't allow things like exclude >> guest. > > I believe we don't need to try so hard to detect if sampling is > supported or not. I hope we will eventually add that to the > kernel. Also this is just an additional defense line, it should > work without it in most cases. It'll just protect from a few edge > cases like uncore PMUs having events of legacy name. For > other events or PMUs, I think it's ok to fail. > > >> 2) Ignore failures, possibly hiding user errors. >> >> I would prefer for (2) the errors were pr_err rather than pr_debug, >> something the user can clean up by getting rid of warned about PMUs. >> This will avoid hiding the error, but then on Neoverse cycles will >> warn about the arm_dsu PMU's cycles event for exactly Linus' test >> case. My understanding is that this is deemed a regression, hence >> Arnaldo proposing pr_debug to hide it. > > Right, if we use pr_err() then users will complain. If we use > pr_debug() then errors will be hidden silently. > > Thanks, > Namhyung I'm not sure if anyone would really complain about warnings for attempting to open but not succeeding, as long as the event that they really wanted is there. I'm imagining output like this: $ perf record -e cycles -- ls Warning: skipped arm_dsu/cycles/ event(s), recording on armv8_pmuv3_0/cycles/, armv8_pmuv3_1/cycles/ [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.008 MB perf.data (30 samples) ] You only really need to worry when no events can be opened, but presumably that was a warning anyway. And in stat mode I wouldn't expect any warnings.