Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3993427ybc; Thu, 14 Nov 2019 19:05:08 -0800 (PST) X-Google-Smtp-Source: APXvYqxxiHIAKW/Db/reJvt66pYZ9ABxF9Hy4WiJcOMbIDr5DcuCy7840RH4P9D6N8MhFZH7lIw0 X-Received: by 2002:a17:906:24d4:: with SMTP id f20mr10706624ejb.182.1573787107910; Thu, 14 Nov 2019 19:05:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573787107; cv=none; d=google.com; s=arc-20160816; b=z5aoLnswvaPOff+0ZOCyaJh5meAE1uAWDC22VgtO+K9QkeOwJ/y7goIep4931wpF2l HTYKRWjAV6P+ariT1M+Xv8PVpKyp2o+eVWcITAq4HsFtvMRZllRQpotHYNUkgPcL680m JGri9zZiHAars1Yfj5qBIKp03E1bCvfwpJ/58X4UuWHkPQh32rfJhU65mmCwVRiyXl5+ +UuwwF9suHykI7MswiMV9VhR1iAhxBsbeDGh4DVE4SZJ6W/9HSdCx2XUqvV13zQ57mt6 jMjYgf1yjrJ9rMyeETUwjOkRtzha7ZaAc5R7AyuI80VVJKdtqPHf3ws3OkCWBcCya53O GG6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Mz1fWBmwfQMhw1COo6mZqbmx1TY+XkRRNvVchvI3BO0=; b=fMGubIwsmjTrGyGDHLEYmepcGevFAjWCCOWfKVUeahcmBZStGm/MprDiHTiwIoPGo2 czsaYiHUSlQNyc5rLllmPW/S+v07oYE51F3V5ugt3RnjE7KRUPG4kYkeTVLjXFxg9pVl 1V38VWZ70U90/5eri8yy2Z0o5wNx+9Zqfpg3crk6bOJZtCK4XJiR35qOSJ2ri/4XlNhj 5AuuWJGuiuRedenhMBrGh7N1f5jXm+LNwXpvLTRcrkePU0aXdHjNdh1EiEIe4NLHGXmx bjwZHWfZg84mU0szS2EC72K572ckBR+ChPUiwTSrwLlKJ/zGIGkNskkxY9tgOCsXuTds bNJA== 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 a60si5604719edf.169.2019.11.14.19.04.41; Thu, 14 Nov 2019 19:05:07 -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 S1727059AbfKOC7w (ORCPT + 99 others); Thu, 14 Nov 2019 21:59:52 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:6231 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726674AbfKOC7w (ORCPT ); Thu, 14 Nov 2019 21:59:52 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B3BF4703125ED2C8AE1E; Fri, 15 Nov 2019 10:59:50 +0800 (CST) Received: from [127.0.0.1] (10.133.215.182) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.439.0; Fri, 15 Nov 2019 10:59:45 +0800 Subject: Re: [RFC v2 4/4] perf tools: Support "branch-misses:pp" on arm64 To: James Clark CC: "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , nd References: <20191024144830.16534-1-tanxiaojun@huawei.com> <20191024144830.16534-5-tanxiaojun@huawei.com> <38c18a3e-1b9a-05fe-63f6-920af2f53fc7@huawei.com> <609eb078-7998-9e4a-ca04-6c40a8a47f84@arm.com> From: Tan Xiaojun Message-ID: <7137fecb-a0bd-6dee-14c9-5753e56d39a1@huawei.com> Date: Fri, 15 Nov 2019 10:59:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <609eb078-7998-9e4a-ca04-6c40a8a47f84@arm.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.133.215.182] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/11/13 22:47, James Clark wrote: > Hi Xiaojun, > >> I can't reproduce this problem. If the current system doesn't support spe, it shouldn't report an error. I use the latest codes of the mainline: > > I think the problem is related to the 'type' attribute of the event. To open the SPE PMU the event type on the platform I'm using is '7'. If I change > the code like this, the problem is fixed: > > @@ -914,13 +914,27 @@ void arm_spe_precise_ip_support(struct evlist *evlist, struct evsel *evsel) > pmu = perf_pmu__find("arm_spe_0"); > if (pmu) { > evsel->pmu_name = pmu->name; > - evsel->core.attr.type = PERF_RECORD_AUXTRACE; > - evsel->core.attr.config = SPE_ATTR_TS_ENABLE > - | SPE_ATTR_PA_ENABLE > - | SPE_ATTR_JITTER > + evsel->core.attr.type = pmu->type; > + evsel->core.attr.config |= SPE_ATTR_TS_ENABLE > | SPE_ATTR_BRANCH_FILTER; > Hi, James, OK. Thank you for your fix. > Also do you think jitter should be enabled by default? I thought that it might make the data less precise, so I removed it here. Since the interval for sampling without "jitter" is fixed (default 1024 on our server), I was worried that not adding it would result in the same result for each record, and some instructions could not be collected each time. However, after many tests, it is not clear from the results that there is a significant difference between them (enable it or not). So I am confused, whether to enable it or not. Thanks. Xiaojun. > > -James > >> >> commit f116b96685a046a89c25d4a6ba2da489145c8888 (mainline/master) >> Merge: f632bfaa33ed 603d9299da32 >> Author: Linus Torvalds >> Date: Thu Oct 24 06:13:45 2019 -0400 >> >> Merge tag 'mfd-fixes-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd >> >> I will go and see why this will be reported. >> >>> >>> >>> I would have expected to use the event name that is listed in the SPE documentation for branch misses which is br_mis_pred or br_mis_pred_retired: >>> >>>     E[7], byte 0 bit [7] >>>     Mispredicted. The defined values of this bit are: >>>     0 Did not cause correction to the predicted program flow. >>>     1 A branch that caused a correction to the predicted program flow. >>> >>>     If PMUv3 is implemented this Event is required to be implemented consistently with either BR_MIS_PRED or BR_MIS_PRED_RETIRED. >>> >> >> Do you mean that I can add these as new events to perf? If we think of them as new events, what should we do if the user does not add :pp for them? >> (Or for these events, users can only add :pp to use them?) >> >>> >>> +       if (!strcmp(perf_env__arch(evlist->env), "arm64") >>> +                       && evsel->core.attr.config == PERF_COUNT_HW_BRANCH_MISSES >>> +                       && evsel->core.attr.precise_ip) { >>> >>> As I mentioned above PERF_COUNT_HW_BRANCH_MISSESdoesn't seem to match up with the actual event counter that is associated with this SPE event (BR_MIS_PRED). The fix for this is probably as simple as adding an OR for the other aliases for branch mispredicts. >> >> What you mean is that we can filter with spe events(like BR_MIS_PRED) first, and if we have other events that are exactly the same(no more for now), then we can handle them by adding OR in the future? >> >>> >>> +               pmu = perf_pmu__find("arm_spe_0"); >>> +               if (pmu) { >>> +                       evsel->pmu_name = pmu->name; >>> +                       evsel->core.attr.type = PERF_RECORD_AUXTRACE; >>> +                       evsel->core.attr.config = SPE_ATTR_TS_ENABLE >>> +                                               | SPE_ATTR_PA_ENABLE >>> >>> I wouldn't set physical addresses by default as this requires root. I would leave that to the user if they want to manually configure SPE. >> >> Yes. You are right. I got a error for this case. I will fix it. >> >> ------------------ >> ./perf record -e branch-misses:p ls >> Error: >> You may not have permission to collect stats. >> ... >> ------------------ >> >> Thanks. >> Xiaojun. >> >>> >>> I have only looked briefly and I will do some more testing. >>> >>> >>> Thanks >>> James >>> >>> >> >>