From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932602AbcBBQUx (ORCPT ); Tue, 2 Feb 2016 11:20:53 -0500 Received: from mail-oi0-f46.google.com ([209.85.218.46]:35616 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750721AbcBBQUw (ORCPT ); Tue, 2 Feb 2016 11:20:52 -0500 MIME-Version: 1.0 In-Reply-To: References: <1452807977-8069-1-git-send-email-mathieu.poirier@linaro.org> <1452807977-8069-24-git-send-email-mathieu.poirier@linaro.org> <20160125211048.GE22501@kernel.org> <56AB4027.2070208@intel.com> <20160129211208.GB32225@kernel.org> Date: Tue, 2 Feb 2016 09:20:51 -0700 Message-ID: Subject: Re: [PATCH V8 23/23] perf tools: adding coresight etm PMU record capabilities From: Mathieu Poirier To: Arnaldo Carvalho de Melo Cc: Adrian Hunter , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.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 [...] >>> > >>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I >>> > mentioned that on another patch. >>> > >>> > However there is no decoder, which begs the question, is there anything you >>> > can actually do with the perf.data file? Might be a bit confusing for users >>> > if they can capture traces but not use perf tools on the resulting perf.data >>> > file? >>> >>> We are working on a decoding library in parallel to this work. >> >> Would be nice to be able to get both in the same patch kit, no? So that >> one can both record and process the traces, verifying it all works. > > We are still a few weeks away from being in a position where the > community can start playing with the decoding library. I can hold off > on the "perf tools" patches when I queue the kernel side of the work > for 4.6 but since you and Adrian have already reviewed the work it > would be nice to have that part included as well. > > We've been playing with the perf.data files for a couple of months now > and things look at the right place. This isn't surprising since we > are using the same framework as X86. > > I think the generation of the perf.data file should be coupled with > the submission of the kernel driver but would also respect a diverging > point of view. Simply let me know what you prefer and I will adjust > V9 accordingly. Arnaldo, I'm preparing V9 at this time - what's your view on the above? Thanks, Mathieu From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathieu.poirier@linaro.org (Mathieu Poirier) Date: Tue, 2 Feb 2016 09:20:51 -0700 Subject: [PATCH V8 23/23] perf tools: adding coresight etm PMU record capabilities In-Reply-To: References: <1452807977-8069-1-git-send-email-mathieu.poirier@linaro.org> <1452807977-8069-24-git-send-email-mathieu.poirier@linaro.org> <20160125211048.GE22501@kernel.org> <56AB4027.2070208@intel.com> <20160129211208.GB32225@kernel.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org [...] >>> > >>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I >>> > mentioned that on another patch. >>> > >>> > However there is no decoder, which begs the question, is there anything you >>> > can actually do with the perf.data file? Might be a bit confusing for users >>> > if they can capture traces but not use perf tools on the resulting perf.data >>> > file? >>> >>> We are working on a decoding library in parallel to this work. >> >> Would be nice to be able to get both in the same patch kit, no? So that >> one can both record and process the traces, verifying it all works. > > We are still a few weeks away from being in a position where the > community can start playing with the decoding library. I can hold off > on the "perf tools" patches when I queue the kernel side of the work > for 4.6 but since you and Adrian have already reviewed the work it > would be nice to have that part included as well. > > We've been playing with the perf.data files for a couple of months now > and things look at the right place. This isn't surprising since we > are using the same framework as X86. > > I think the generation of the perf.data file should be coupled with > the submission of the kernel driver but would also respect a diverging > point of view. Simply let me know what you prefer and I will adjust > V9 accordingly. Arnaldo, I'm preparing V9 at this time - what's your view on the above? Thanks, Mathieu