Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp125007pxy; Wed, 21 Apr 2021 20:53:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfa/1e/5ZW49elkKxWAwPCzeA37ih6VUA48LbIalPTL6thHT4pfDB+6Y2CaZZzcNpZ6+NI X-Received: by 2002:a05:6402:27ce:: with SMTP id c14mr1213056ede.263.1619063610841; Wed, 21 Apr 2021 20:53:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619063610; cv=none; d=google.com; s=arc-20160816; b=EyIz6rAz7yETZgxJqrungIiMyHBCHwDin2/ZsIuqWScx0msbxnWTcPbzAhQrMaiNck smbnmB9YiNRHJdMpyPdLhmoL7x/YM7aJ7VgmYxlwNzE0jq9iv8igj/uDr3l8ogVagsYX pzRXl54j6Rw9Q5KvTvKQ1TN4fgvb0rH27kifHIBHWHwyGh+i6M3Kt683Fx4tPx27T3Zw 8G/pLxww6hmJHZddYUtYw/JBhJOA4xDsEl9SxuK45yIa5xKjvOwQC7SU57ZQS4SA4xtn YIxaXT9StAZfYxrjbFSj++KfIlr75amYEQjBPK1MJXCUogOvSWdmMxuvgSW2DEAybizZ XjfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KlLhNuqFuzAH3Dvaau9RXCpdk7wAfkXaC/QsSXDFqAI=; b=OJ3lrTj6Dbi187tnamkDpQyh5ULwU7fZNEt0+Vqfe4e8Qld3qm4UDl4TOhgE5yJBgW vHmGjm4RlxL4tpAzC1+UuaWd30Qw1I8+IsKLqF+vQ/3xA2HFFn6g04+zudPR5/2TKQMx FbcZa70gKHyoiPO9GybbG0v2PDLGP4padLqFC9p8u6Fp1cmH/KMHD3KkHfP7gDVS6xEP 865eLoAG2fnOqfOZ4NsObFE44C0rgCa1CPG1ggnrqS4myj4WMB4PBrB3yFGDdDVipu+X MuDeODv4JjL7Nz6NCcLGGsqp01nPrxhawBbvYYZf0f/G35R011vELNR4J/cyYXcvaK2E NCxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=lOEkPYQi; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f16si1244350edy.531.2021.04.21.20.53.06; Wed, 21 Apr 2021 20:53:30 -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; dkim=pass header.i=@linaro.org header.s=google header.b=lOEkPYQi; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234258AbhDVDuL (ORCPT + 99 others); Wed, 21 Apr 2021 23:50:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231997AbhDVDuL (ORCPT ); Wed, 21 Apr 2021 23:50:11 -0400 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B213C06174A for ; Wed, 21 Apr 2021 20:49:37 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id j7so22471667pgi.3 for ; Wed, 21 Apr 2021 20:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KlLhNuqFuzAH3Dvaau9RXCpdk7wAfkXaC/QsSXDFqAI=; b=lOEkPYQi9bBU+LVprM/puFZ5zkeovcvDT4PZOtupVJu7etYqUXQ8HKLZXR5LoYY+s7 64kdrulRwsmfSLRGYjKmtKdtG8Z3+8sZiSBupH5WBRipImvAqPXSKSHYYpC1h0eyAbdy MQJTNX8tO3ZxpsxAgmmluMqgqxWC2VoghvCyXOi1N+OKJrvo2iW7APMWpfpRAeT3Ku6i MkpKVoMLD3sBQq5Vkp4AVqm80/trIS5+ylJC74J/HZTKEJVvFvsz1wakXeYkQ3Wmfc1F Y6SS45I1Wzyq0bac6VmDi5nLKHC1HfIElsvqPmx2XbzORt6spcWEjc4tlUAy1oKs/1Ma lGYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KlLhNuqFuzAH3Dvaau9RXCpdk7wAfkXaC/QsSXDFqAI=; b=EKfDTCK4XxUtGxUJtmWrMFYY2XvM7rGrUG1BapRK7EyytR2vh5aq/9xhs1i80t+yAl lu9iT5wUBlVz8mmIhZr5ibh96kr/aHcW/biTTmRpwZmUbmBsXIS/O7KqXnXsuH2HGSxn LShGBNxcJnzRN18TiVLDR95Lz5WMTIZI9Vm7WovMEGXN6tMnVBNGDc6VWCXnE7gU9NYX 9pS1ggDXIw4HCCJs/nGUOH1TCr+phylVEpWivuyA62OkGAGM/ORWRTxtYQtWlW4hSZJa zPPxBEZ6RgcPghni8M12vWZo04W/hCCHGgipRkZWzCBa3g6ExBb2SLp0Spla0QfyS7Rl cNtg== X-Gm-Message-State: AOAM532nkWY6Rd8adOSPEA/vxhpn19SukdrTz+LjUEbLusq6Zx1hS8XG y0n4LMEUR/RvAMFXO6r8s7Me3Q== X-Received: by 2002:aa7:80c9:0:b029:249:cac5:e368 with SMTP id a9-20020aa780c90000b0290249cac5e368mr1393699pfn.12.1619063376568; Wed, 21 Apr 2021 20:49:36 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([116.206.101.232]) by smtp.gmail.com with ESMTPSA id i66sm719546pgd.8.2021.04.21.20.49.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 20:49:35 -0700 (PDT) Date: Thu, 22 Apr 2021 11:49:29 +0800 From: Leo Yan To: Yicong Yang Cc: Alexander Shishkin , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, linux-pci@vger.kernel.org, helgaas@kernel.org, gregkh@linuxfoundation.org, lorenzo.pieralisi@arm.com, will@kernel.org, mark.rutland@arm.com, mathieu.poirier@linaro.org, suzuki.poulose@arm.com, mike.leach@linaro.org, jonathan.cameron@huawei.com, song.bao.hua@hisilicon.com, john.garry@huawei.com, prime.zeng@huawei.com, liuqi115@huawei.com, zhangshaokun@hisilicon.com, linuxarm@huawei.com Subject: Re: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace device Message-ID: <20210422034929.GA13004@leoy-ThinkPad-X240s> References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com> <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com> <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 19, 2021 at 09:03:18PM +0800, Yicong Yang wrote: > On 2021/4/17 21:56, Alexander Shishkin wrote: > > Yicong Yang writes: > > > >> The reason for not using perf is because there is no current support > >> for uncore tracing in the perf facilities. > > > > Not unless you count > > > > $ perf list|grep -ic uncore > > 77 > > > > these are uncore events probably do not support sampling. > > I tried on x86: > > # ./perf record -e uncore_imc_0/cas_count_read/ > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_imc_0/cas_count_read/). > /bin/dmesg | grep -i perf may provide additional information. > > For HiSilicon uncore PMUs, we don't support uncore sampling: > > 'The current driver does not support sampling. So "perf record" is unsupported. ' [1] > > and also in another PMU: > > 'PMU doesn't support process specific events and cannot be used in sampling mode.' [2] > > [1] Documentation/admin-guide/perf/hisi-pmu.rst > [2] Documentation/admin-guide/perf/arm_dsu_pmu.rst I did some debugging for this, and yes, it's related with the event doesn't support sampling for these x86 uncore events. So I can use below commands for the uncore event 'uncore_imc/data_reads/' in my experiment: # perf record -e 'uncore_imc/data_reads/' --no-samples -- ls # perf stat -e 'uncore_imc/data_reads/' -- ls For your case, I think you need to write the callback pmu::event_init(), it should not forbid any tracing even if set sampling, just like other perf event drive for support AUX tracing. > >> We have our own format > >> of data and don't need perf doing the parsing. > > > > Perf has AUX buffers, which are used for all kinds of own formats. > > > > ok. we thought perf will break the data format but AUX buffers seems won't. > do we need to add full support for tracing as well as parsing or it's ok for > not parsing it through perf? IMHO, this could divide into two parts. The first part is to enable perf drive with support AUX tracing, and perf tool can capture the trace data. The second part is to add the decoder in the perf tool so that the developers can *consume* the trace data; for the decoder, you could refer the codes: tools/perf/util/intel-pt-decoder/ tools/perf/util/cs-etm-decoder/ Or Arm SPE case: tools/perf/util/arm-spe-decoder/ > >> A similar approach for implementing this function is ETM, which use > >> sysfs for configuring and a character device for dumping data. > > > > And also perf. One reason ETM has a sysfs interface is because the > > driver predates perf's AUX buffers. Can't say if it's the only > > reason. I'm assuming you're talking about Coresight ETM. I am not the best person to give background for this. Mathieu or Mike could give more info for this. From my undersanding, Sysfs nodes can be used as knobs for configuration, but it's difficult for profiling. Let's think about for the profiling, if one developer uses the Sysfs for the setting and read out the trace data, these informations are discrete. If another developer wants to review the profiling result, then all these info need to be shared together. So we can benefit much from the perf tool for the usage, since all the profiling context will be gathered (DSOs, hardware configuration which can be saved into metadata), so the final profiling file can be easily shared and more friendly for reviewing. Thanks, Leo