Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754537AbbERRaY (ORCPT ); Mon, 18 May 2015 13:30:24 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:35360 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754011AbbERRaU (ORCPT ); Mon, 18 May 2015 13:30:20 -0400 MIME-Version: 1.0 In-Reply-To: <20150508162143.GQ27504@twins.programming.kicks-ass.net> References: <1431008154-6833-1-git-send-email-robert@sixbynine.org> <20150508162143.GQ27504@twins.programming.kicks-ass.net> From: Robert Bragg Date: Mon, 18 May 2015 18:29:57 +0100 X-Google-Sender-Auth: eyyOux2akz6KktUH2MK25hOmVcY Message-ID: Subject: Re: [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU To: Peter Zijlstra Cc: intel-gfx@lists.freedesktop.org, Daniel Vetter , Jani Nikula , David Airlie , Paul Mackerras , Ingo Molnar , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-api@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2162 Lines: 52 On Fri, May 8, 2015 at 5:21 PM, Peter Zijlstra wrote: > > So I've not yet went through the entire series; but I'm wondering if its > at all possible to re-use some of this work: > > lkml.kernel.org/r/1428453299-19121-1-git-send-email-sukadev@linux.vnet.ibm.com > > That's for a Power8 HV call that can basically return an array of > values; which on a superficial level sounds a bit like what this GPU > hardware does. Thanks for this pointer. I think the main similarity here is the ability to capture multiple counters consistent for the same point in time, but in our case we don't have an explicitly controlled transaction mechanism like this. Although we can collect a large set of counters in a latched fashion - so they are self consistent - the selection of counters included in our OA unit reports is more rigid. Most of our counters aren't independently aggregated, they are derived from signals selected as part of the OA unit configuration and the values are only maintained by the OA unit itself, so a re-configuration to select different signals will discard the counter values of currently selected signals. afik re-configuring our signal selection is also relatively slow too (I was told this last week at least, but I haven't tested it myself) and so it's really geared towards applications or tools choosing a configuration to maintain for a relatively long time while profiling a workload. I think the other big difference here is that we don't have a way to explicitly trigger a report to be written from the cpu. (Although we can read the OA counters via mmio, it's only intended for debug purposes as this subverts the hw latching of counters) This means it would be difficult to try and treat this like a transaction including a fixed set of event->read()s without a way for pmu->commit_txn() to trigger a report. > > Let me read more of this.. Thanks. - Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/