From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751442AbbIXITX (ORCPT ); Thu, 24 Sep 2015 04:19:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35567 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbbIXITT (ORCPT ); Thu, 24 Sep 2015 04:19:19 -0400 Date: Thu, 24 Sep 2015 10:19:12 +0200 From: Jiri Olsa To: kan.liang@intel.com Cc: acme@kernel.org, jolsa@kernel.org, a.p.zijlstra@chello.nl, mingo@redhat.com, namhyung@kernel.org, ak@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 00/10] counter read during perf sampling Message-ID: <20150924081912.GE2024@krava.redhat.com> References: <1442931223-51708-1-git-send-email-kan.liang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442931223-51708-1-git-send-email-kan.liang@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2015 at 10:13:33AM -0400, kan.liang@intel.com wrote: > From: Kan Liang > > The patch series intends to read counter statistics with fixed frequency > during sampling. The instant benefit is that we can read memory bandwidth > from uncore event during cpu PMU event is sampling. > > Introduce 'C' event/group modifier. The event with this modifier > will do counting not sampling. If a group with this modifier, only > group leader do sampling. The counter statistics will be wrote in > new RECORD type PERF_RECORD_COUNTER_READ and stored in perf.data. > So perf report can present the counter statistics data accordingly. > > There may be an alternative way to get counter statistics during > sampling by running perf record and perf stat together by script. > But the script way have various issue and complex to parses the > output. just a thought, but isn't the way then llow to store the data from perf stat? ;-) and be able to merge perf.data-s from perf record and stat afterwards > > Example: > > $perf record -e 'cycles,uncore_imc_1/cas_count_read/C' > --counter-read-interval 10 -a ./tchain_edit > [ perf record: Woken up 438 times to write data ] > [ perf record: Captured and wrote 1.232 MB perf.data (17901 samples) ] but if we go this way I think we should keep/allow all the options perf stat something like: $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 -a ./tchain_edit with all the stat option we allow -c -F ... and reusing existing stat code > $perf report -D > > 0x3cae0 [0x28]: PERF_RECORD_COUNTER_READ: uncore_imc_1/cas_count_read/C > CPU 0: val 1205 ena 2046148 run 2046148 > > 0x3cb08 [0x28]: PERF_RECORD_COUNTER_READ: uncore_imc_1/cas_count_read/C > CPU 18: val 1315 ena 2001918 run 2001918 > > 0x3dba0 [0x28]: PERF_RECORD_COUNTER_READ: uncore_imc_1/cas_count_read/C > CPU 0: val 1588 ena 12191520 run 12191520 > > 0x3dbc8 [0x28]: PERF_RECORD_COUNTER_READ: uncore_imc_1/cas_count_read/C > CPU 18: val 1686 ena 12162202 run 12162202 > > $perf report --stdio --socket-filter 0 > > # To display the perf.data header info, please use --header/--header-only options. > # > # > # Total Lost Samples: 0 > # > # Samples: 17K of event 'cycles' > # Event count (approx.): 10119095556 > # Processor Socket: 0 > # > # Overhead Command Shared Object Symbol > # ........ ............ ................... .................................. > # > 97.68% tchain_edit tchain_edit [.] f3 > 0.07% tchain_edit tchain_edit [.] f2 > 0.04% swapper [kernel.vmlinux] [k] run_timer_softirq > 0.04% swapper [kernel.vmlinux] [k] find_busiest_group > > # Samples: 0 of event 'uncore_imc_1/cas_count_read/C' > # Event count (approx.): 0 > # Processor Socket: 0 > # uncore_imc_1/cas_count_read/C: 35937 I think we'll need special output/display for non sampling events, something like extra window in TUI and distinguished output in stdio, the above is hacked sampling output ;-) thoughts? jirka