Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4034000ybg; Fri, 25 Oct 2019 12:22:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxlCRj+LG3FQgwD5nH/V/qemtcr+50VSI2NZeO4rtfr+jgcSZmw5XnMBjozL5IYyWldTgTf X-Received: by 2002:a50:b6f8:: with SMTP id f53mr5756799ede.29.1572031335896; Fri, 25 Oct 2019 12:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572031335; cv=none; d=google.com; s=arc-20160816; b=rwMpzhXN87jAnZ6drvzjuTZAU4gGBmbUE5GdhSfLMgmChpwq/Rv8tT/toP4PIRRQiA uu+YSRfUrc4Ua1ihln4WX6+Im/u02NZEjzzHqhDySeAop5+wvQkptW6YpIJYwnrgeAsl lwJY25y3LNzdoEnP3VUqdO7ElI8gq2D4uvBI5F+wIF6cGTgm81oy0gghm9/3M5XToHe3 lsAQDtAf44DY4YgMydcAvCh5lyqlGwbdSzUVMps6yBge1vWoikicJkSpgBk+KWg/MEXF +JStrAKwmv/SwYlGAizGEE4DMdAKr/eLaY3++WDIv5DpSeXHSWnDpRUN/Xxk+rSEbZQy fzVg== 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=OOWNXaIX1Wc0Y8EHFNKdyrTo4Rq1Sb7GYG3R1DXz480=; b=b9kZJfszlYILCJSFH6UFgRFoAUFyXCMV4sDcmF+Vt46m6eUU6We2/FnmEXCxySmu7k adLr9xXAHM7ATQkN/Pka+Kb/10tDaT7ore7MTnEM5DvEfdFDRGkUpoWHxpf1KJgO+sN4 4xWbSux9He6/Wt7AfEHdAdzdk58Wl+Z2mtBUbjNGfXVZKKW2Ad0RHu9EAns4vh4R7sM2 SMbSchYimT2nw8v8N0OJbFh2Zk5299CQCxFqnkal7HihoVfyH4Knfk5TiCdOTyXS236z XK+yRaQNfCfrEGnja5Rxvl2gU6zZyYyICtA/zQx9vVvUF1By+BQSjU4ycYI5WF+AUOnH huHA== 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 d6si1859016ede.119.2019.10.25.12.21.52; Fri, 25 Oct 2019 12:22:15 -0700 (PDT) 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 S2390605AbfJYCnS (ORCPT + 99 others); Thu, 24 Oct 2019 22:43:18 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:40876 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728416AbfJYCnR (ORCPT ); Thu, 24 Oct 2019 22:43:17 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id DE9FAA2158D1DA85FDC8; Fri, 25 Oct 2019 10:43:03 +0800 (CST) Received: from [127.0.0.1] (10.133.215.182) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.439.0; Fri, 25 Oct 2019 10:42:54 +0800 Subject: Re: [RFC v2 4/4] perf tools: Support "branch-misses:pp" on arm64 To: James Clark , "peterz@infradead.org" , "mingo@redhat.com" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , "jolsa@redhat.com" , "namhyung@kernel.org" , "ak@linux.intel.com" , "adrian.hunter@intel.com" , "yao.jin@linux.intel.com" , "tmricht@linux.ibm.com" , "brueckner@linux.ibm.com" , "songliubraving@fb.com" , "gregkh@linuxfoundation.org" , Kim Phillips , "Jeremy Linton" CC: "gengdongjiu@huawei.com" , "wxf.wang@hisilicon.com" , "liwei391@huawei.com" , "huawei.libin@huawei.com" , "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> From: Tan Xiaojun Message-ID: <38c18a3e-1b9a-05fe-63f6-920af2f53fc7@huawei.com> Date: Fri, 25 Oct 2019 10:42:52 +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: 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/10/25 0:29, James Clark wrote: > Hi Xiaojun, > > This looks really good. I tried this, but got an error: > >     ./perf record -e branch-misses:p ls >     Error: >     The branch-misses:p event is not supported. Hi, James, 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: 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 > >