From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33D98C4332B for ; Thu, 19 Mar 2020 11:22:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 050C02070A for ; Thu, 19 Mar 2020 11:22:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="jPns8Zj4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727039AbgCSLWH (ORCPT ); Thu, 19 Mar 2020 07:22:07 -0400 Received: from bilbo.ozlabs.org ([203.11.71.1]:37961 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726982AbgCSLWG (ORCPT ); Thu, 19 Mar 2020 07:22:06 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 48jkyJ4c93z9sQt; Thu, 19 Mar 2020 22:22:00 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1584616922; bh=EEchnxXtnjsxaM2QrIQOc4QB6WvA6Z7scPBjPCIHTLw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jPns8Zj45gHQLCIXDaac06BYlBNrlEfdIA/AyVRhSvWuFR+bSj6L3xUOlxAeLAT7Y IimhyEhBlVePcdOLNWU++TkB4dTNn6/fWpVDVzmvLjSRL3n+C/bhTKCIBp4ybK2VI4 a818JY9LzjnY7BK8obSeDZhTko1z2dzxiS8xhKrpPOT8TKQkcLFCeG5P9tUM5guDbT 7RbLWW+cSm/44zSyDEzwJxehyxpWzR3KojDp6N0uEB/+QwcwpUf5bdTr1YJv9TMO2b VcZK/Ck0u0ikk8DV+5ArdmgIiZ9GPL+iW4lOqXAPiOit4L52Yeq+QY6sN9tQYGf407 D2r+081Ra/Mhw== From: Michael Ellerman To: Kim Phillips , maddy , Ravi Bangoria Cc: Stephane Eranian , Peter Zijlstra , linuxppc-dev@lists.ozlabs.org, LKML , Paul Mackerras , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Adrian Hunter , Andi Kleen , "Liang\, Kan" , Alexey Budankov , yao.jin@linux.intel.com, Robert Richter Subject: Re: [RFC 00/11] perf: Enhancing perf to export processor hazard information In-Reply-To: <8803550e-5d6d-2eda-39f5-e4594052188c@amd.com> References: <20200302052355.36365-1-ravi.bangoria@linux.ibm.com> <20200302101332.GS18400@hirez.programming.kicks-ass.net> <2550ec4d-a015-4625-ca24-ff10632dbe2e@linux.ibm.com> <8a4d966c-acc9-b2b7-8ab7-027aefab201c@linux.ibm.com> <0c5e94a3-e86e-f7cb-d668-d542b3a8ae29@linux.ibm.com> <8803550e-5d6d-2eda-39f5-e4594052188c@amd.com> Date: Thu, 19 Mar 2020 22:22:03 +1100 Message-ID: <87o8ssd1yc.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kim Phillips writes: > On 3/17/20 1:50 AM, maddy wrote: >> On 3/13/20 4:08 AM, Kim Phillips wrote: >>> On 3/11/20 11:00 AM, Ravi Bangoria wrote: >>> >>>> information on each sample using PMI at periodic intervals. Hence proposing >>>> PERF_SAMPLE_PIPELINE_HAZ. >>> >>> And that's fine for any extra bits that POWER9 has to convey >>> to its users beyond things already represented by other sample >>> types like PERF_SAMPLE_DATA_SRC, but the capturing of both POWER9 >>> and other vendor e.g., AMD IBS data can be made vendor-independent >>> at record time by using SAMPLE_AUX, or SAMPLE_RAW even, which is >>> what IBS currently uses. >> >> My bad. Not sure what you mean by this. We are trying to abstract >> as much vendor specific data as possible with this (like perf-mem). > > Perhaps if I say it this way: instead of doing all the > isa207_get_phazard_data() work past the mfspr(SPRN_SIER) > in patch 4/11, rather/instead just put the raw sier value in a > PERF_SAMPLE_RAW or _AUX event, and call perf_event_update_userpage. > Specific SIER capabilities can be written as part of the perf.data > header. Then synthesize the true pipe events from the raw SIER > values later, and in userspace. In the past the perf maintainers have wanted the perf API to abstract over the specific CPU details, rather than just pushing raw register values out to userspace. But maybe that's no longer the case and we should just use PERF_SAMPLE_AUX? cheers