Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1382730imm; Thu, 4 Oct 2018 12:41:49 -0700 (PDT) X-Google-Smtp-Source: ACcGV615nmaFapiGfYb4nccH2gL/Acr6db5A5PG0uNcTDx0GjXmbP2Y19p2fFKlBff+u8Bnjc6WQ X-Received: by 2002:a63:4a64:: with SMTP id j36-v6mr7082668pgl.168.1538682109352; Thu, 04 Oct 2018 12:41:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538682109; cv=none; d=google.com; s=arc-20160816; b=o2lG0gFFkWIZex6XDvyZEG8EqGaeTmQnHbU4zGzkZhMt/BMJCcDxDcYYz+XFWgDHgE /WDLLOV9EKsljIwwQK7hmvH9NYV+w623oiA2ilIirNPPwDfnHKZuOMKE4TrtzmTNxr1T LNrNNi2fo5d6hpQb1MtZ+OQIbL6Uh3Vtun0rL/HSUUGfhgtsEEPdevjf5LVRGdjMXDr2 XfNEWYzUd1EqNPnrJOxVFxIWZozfIEG8C4l6it58na6q5wcC87MaqfkKV1y3gJIxSk+7 wF1uA6xE1ExdHv8ph3HoFQotslPfKr5xJOAUJNb/gQjWTitl8zjxjsRkT05FN2/SGD9c DQ0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=y4kQ8VJxC3cT+BnlsYuBYZJ7ENAvD+eaH4vZhPmOGWs=; b=lf0RI3wYVGciJHOW2iMWJGOTd+YtGAcMg7xXuRfpYmkPtz+eb4LYmlfDdvwdgXy8b5 fEETHg+bxMGp3LnZ6HJj7rCyTp0waVFh/8GBt4PAN/7XLZiMLd1KYAtW6JBEv3UUAklP Xh8cwINg5PC5xVMr08btA6vAqJqN139E2dNMVYoXlQ6gKwfBfheXe0uHU5Je72rtbzjp tabvWO2cb78GmNZ/9a/quNV1v+tH6oO9VlII3ZzE/jvqxokLYSv92H3iiXCtTXT19ZV3 1b+GwItDrzo6xO1+CMrjuTfR5C78sU1EjJJxwEQATOUT4WJmhUN3RFZtYSMchYDnMFI4 cFLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ourg54zZ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e83-v6si6086262pfk.198.2018.10.04.12.41.34; Thu, 04 Oct 2018 12:41:49 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ourg54zZ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727578AbeJECe2 (ORCPT + 99 others); Thu, 4 Oct 2018 22:34:28 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:36357 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727354AbeJECe2 (ORCPT ); Thu, 4 Oct 2018 22:34:28 -0400 Received: by mail-oi1-f193.google.com with SMTP id p125-v6so8499928oic.3 for ; Thu, 04 Oct 2018 12:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y4kQ8VJxC3cT+BnlsYuBYZJ7ENAvD+eaH4vZhPmOGWs=; b=Ourg54zZ9jTMCGImlUYvrln9xXvblGsyrJYSCFDVfTWfmigYQFyBSGz5zu6GB0/Rid ADMtOcs0WLqfVIUaBaXpIhw+Db9hTR990kzZp+bnj0Cwd82WEa4YtU8fKEVNuc4RLWmM 9TM4VH89hffOLIMbXoCN0UzX0qdIH0HJpgXGemts766GXx864pqbd6ka+UfFKDwRzBR5 A3buJkrw9zQX2+ECbmFrHyvdSs4O+hAsGNx5QwqkgqzlD9kBMkfHyTtQNuLNKU7N827s ACW1d4pv8M0kFsY5T9bEwG5InWYm0Lb/UeeDcXOGROBRQMcgsicPNmkQozyuAmTto3iJ +CuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y4kQ8VJxC3cT+BnlsYuBYZJ7ENAvD+eaH4vZhPmOGWs=; b=oq4sC0IL3f6RWawaRPIA5ImpD02I8iUuAm8XgdUYVZbhjTuewcQ/8VzWWPkt7YmLha xrkcVhbbjLEuF95XGbQ09wHtr/rv12LgPT8zWYZl1Zp/oSkzpo0dLn5xYEoBinZMLXOe ZGbxM7Aq3s6dEgrFA4QI3ekwV+AhucxwQsQ+NJvXW4BoWWHAc2cxZlrQKP5o+jSDM8Ze p4kzeWrwBtGWFFLVQ4X+50XSciTxlskMgvDgZlgy5JXi9RYEn06mFyLlWeoKRspdlPMT 1ESZUfhTQ+PjJ1peCF00F0JxaCOXnV1v3IQMbNZt9C+k2JvcQmNMgeopVyrDmwrE6jB0 994Q== X-Gm-Message-State: ABuFfoggPUJLTtVNZt58YzrP4RuJ2Vx4awKR6lferBwdvIUuaTDizpxL 7fFyBgvQW5e/w786Jmz8tLcdidtDF9qT6OMAHQM= X-Received: by 2002:aca:c54f:: with SMTP id v76-v6mr3527410oif.276.1538681984887; Thu, 04 Oct 2018 12:39:44 -0700 (PDT) MIME-Version: 1.0 References: <20181001100707.16840-1-ganapatrao.kulkarni@cavium.com> <20181001142914.GD9716@arm.com> <20181004122207.GE4065@arm.com> In-Reply-To: <20181004122207.GE4065@arm.com> From: Ganapatrao Kulkarni Date: Fri, 5 Oct 2018 01:09:33 +0530 Message-ID: Subject: Re: [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events. To: Will Deacon Cc: Ganapatrao Kulkarni , LKML , linux-arm-kernel@lists.infradead.org, Mark Rutland , catalin.marinas@arm.com, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , "Nair, Jayachandran" , Robert Richter , Vadim.Lomovtsev@cavium.com, Jan.Glauber@cavium.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, On Thu, Oct 4, 2018 at 5:51 PM 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? IIUC, dTLB-load-misses is mapped to ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL(event 0x05) and dTLB-loads is mapped to ARMV8_PMUV3_PERFCTR_L1D_TLB(0x25). Which are as per spec, counts TLB access/misses for both memory-read operation and memory-write operation. IMO, It won't help in keeping these events, knowingly that their mapping is not accurate, only thing i can say to users is , dont use events that are marked as "Hardware cache event" > > 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. yes, i did not find any mapping in PMCEIDx registers for implementation defined events, otherwise we would have remapped at runtime. > > Will thanks Ganapat