Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp380597imm; Fri, 5 Oct 2018 05:27:47 -0700 (PDT) X-Google-Smtp-Source: ACcGV61iZoKliwQIVupOG3F6dyUuFUkB/wakeK1u/LYL7NKvFcPQglQPyBwWwQpMkDNwghhIjEWw X-Received: by 2002:a17:902:bd06:: with SMTP id p6-v6mr11148053pls.226.1538742467726; Fri, 05 Oct 2018 05:27:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538742467; cv=none; d=google.com; s=arc-20160816; b=KG17g7CUp4Dd1VHgE8SPCrMnffkIa2fsStuwbordQW9owRs96JgWIw6kL4aVOsSWmk y7Ws3FWRHuynKB65SXUufi2Lw72dL4tk89xVLC7BFKxhkblysAnu+W5hBajZON9mSE+N 6JB4R6KhiIPmVdm3JaLR9qnqGNXq79HAIfKx2JcmWBFCNAHKCqkZmkG37JSDTzW5/HTE D6g1WAnuUsUYIpER8hcV8JsGgnfPMGH1I/j2Ad6fDxMqwdoC/xMavtwkJJkmr3gnX0uF YHqQEbfyUWONbMewfZ/jCG/NJVHh5gbdR3SjJ8ocLtXN96YB/RGBbjfVewrH5xlfXPSe efIQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=T6uPa0cM+z+gspgHJ1OwxWyc1OaHhybTsPkqTXELuo8=; b=z/bMnTGMv4MHqM7fbqH+9KDpX9mPUoVzZqsU5NdET44JiIR9MELA2rLjmQ6UjIHv+z z1Y4d9OOxsDLTpXBfPyUwDTAPjBX+ozqVxLoOmFwIaS/Y/COtTyJjTeZoElUx9G/Yx7H flOAQVuPKR6Ykqx7PUFuh3s1osHBfjcLTsOnFM015ITcff/mIgCOlrpatI1z9XRSckCs ZCiCyg48D3cSt8lJgE9p06z3mMbBwEWCuGxSVF24Ruh69uGULBsQ3F9axiKhRAkG21X+ 49RwXQ/LjJkEEM8sUJ4PoiOeQY20hbUfchWXyuYuxSNAEY9I8Va8bCOJpBxpIZd5ztW/ JK3Q== 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 o18-v6si8677694pfj.25.2018.10.05.05.27.31; Fri, 05 Oct 2018 05:27:47 -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 S1728181AbeJETZx (ORCPT + 99 others); Fri, 5 Oct 2018 15:25:53 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:13197 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727666AbeJETZw (ORCPT ); Fri, 5 Oct 2018 15:25:52 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 7AEE8D0342DC8; Fri, 5 Oct 2018 20:27:19 +0800 (CST) Received: from [127.0.0.1] (10.202.226.41) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.399.0; Fri, 5 Oct 2018 20:27:16 +0800 Subject: Re: [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events. To: Will Deacon , Ganapatrao Kulkarni References: <20181001100707.16840-1-ganapatrao.kulkarni@cavium.com> <20181001142914.GD9716@arm.com> <20181004122207.GE4065@arm.com> CC: Mark Rutland , "Nair, Jayachandran" , , Peter Zijlstra , , LKML , Arnaldo Carvalho de Melo , Robert Richter , Ingo Molnar , , Ganapatrao Kulkarni , From: John Garry Message-ID: Date: Fri, 5 Oct 2018 13:27:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20181004122207.GE4065@arm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.41] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/10/2018 13:22, Will Deacon wrote: > Hi Ganapat, > > On Thu, Oct 04, 2018 at 11:12:09AM +0530, Ganapatrao Kulkarni wrote: >> can you please pull this patch? > > I still don't like the idea of just removing events like this, especially > when other architectures (including some x86 and Power CPUs afaict) playa > similar games for generic events, and these events do actually appear in > user code. > > I also don't understand why you remove the TLB events. I think that logic > would imply we should remove all of the events, because we can't distinguish > prefetches from reads either. If we want to be consistent, then I think > we should just remove the OP_WRITE events for L1D and BPU -- would you be > ok with that instead? > > Also, looking at the code, I think our PMCEID parsing is broken for 8.1 > parts, where the upper 32 bits of the register are offset by 0x4000 in the > event numbering space. > Here's something I noticed: static ssize_t armv8pmu_events_sysfs_show(struct device *dev, struct device_attribute *attr, char *page) { struct perf_pmu_events_attr *pmu_attr; pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr); return sprintf(page, "event=0x%03llx\n", pmu_attr->id); Should this be min width now be 4, since event width is now 16 bits (even though I don't know why we need to specify this width at all)? Cheers, John > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > . >