From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751049AbdBONQY (ORCPT ); Wed, 15 Feb 2017 08:16:24 -0500 Received: from mail.kernel.org ([198.145.29.136]:49964 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbdBONQW (ORCPT ); Wed, 15 Feb 2017 08:16:22 -0500 Date: Wed, 15 Feb 2017 10:16:17 -0300 From: Arnaldo Carvalho de Melo To: Alexander Shishkin Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, Arnaldo Carvalho de Melo , Borislav Petkov , Thomas Gleixner Subject: Re: [PATCH 2/2] perf/x86/intel/pt: Fail event creation if VMX operation is on Message-ID: <20170215131617.GE4020@kernel.org> References: <20170214132416.26400-1-alexander.shishkin@linux.intel.com> <20170214132416.26400-3-alexander.shishkin@linux.intel.com> <20170214174734.GC4458@kernel.org> <87poijkg25.fsf@ashishki-desk.ger.corp.intel.com> <20170215125128.GB4020@kernel.org> <87a89nk3cq.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a89nk3cq.fsf@ashishki-desk.ger.corp.intel.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Feb 15, 2017 at 03:09:25PM +0200, Alexander Shishkin escreveu: > Arnaldo Carvalho de Melo writes: > > > Em Wed, Feb 15, 2017 at 10:34:58AM +0200, Alexander Shishkin escreveu: > >> Arnaldo Carvalho de Melo writes: > >> > Em Tue, Feb 14, 2017 at 03:24:16PM +0200, Alexander Shishkin escreveu: > >> > Yeah, I saw that as well, and Andi told me about this limitation, so, > >> > for quite a while now, everytime I need to test PT on the only machine I > >> > have with it, I have to stop my kvm sessions :-\ > > > >> > Thanks for working on this! > > > >> Well, we can't make the limitation go away. You'll still have to stop > >> kvms to get any 'meaningful' PT data. > > > > If we can't make the limitation go away we need to at least warn users > > instead of let 'perf record' sit there doing nothing and then at the end > > return as if everything went well only to when trying to use 'perf > > script' nothing will appear. > > I tend to like Peter's idea about PERF_RECORD_AUX with a PAUSED flag to > indicate this. Ok, you mean that I will then be able to start a intel pt session while VMs are there, which will sample nothing, but then, with this session still in place, as soon as I stop all VMs, samples will start appearing on the buffer, then, at report/script/whatever analysis tool start, I'll be able to show the blind spots and say that happened because something prevented PT records from being produced? Would be good to have some indication of _what_ prevented sampling, to not have to say "hey, something banned PT records for a while, maybe VMs?" Best thing I could do would be to correlated that with PERF_RECORD_MMAP for suspecting pathnames. - Arnaldo