Received: by 10.223.176.5 with SMTP id f5csp4414468wra; Tue, 30 Jan 2018 07:01:44 -0800 (PST) X-Google-Smtp-Source: AH8x225llOTDOW+MRGlV+KbV2Fa1xkanvzGh1BJl9+y+j9edCOCm5Vs92jHaZ/fnX9TI2bnNEt0h X-Received: by 10.101.77.208 with SMTP id q16mr1874781pgt.395.1517324504195; Tue, 30 Jan 2018 07:01:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517324504; cv=none; d=google.com; s=arc-20160816; b=x3QOYr/Q63i5pYY6kO62wKUm6D8bBjuJTjHs6TWl6neo+F7NmmcwMFGdlxTK9lnw86 wvHSyJuoEegDn84O54IFFl8yXSQyyd8tFj8ePgym/8lnTXnUrL4ak/ZLQ2MCtb4U3B4D /6m3dZisTlgQbs3tkyp/TtwIbuiRiM2+p/4pUIGWuQKSp1ysiUM1FYfaHT8dINJaoPFl vslKWf0XohXdVE8tk/jIt+E1gp2gcPGJ4n9dCPF3NfJk/aD+PgwxMKrG2CskURJLBP0K HaPLTnaq4+RgD9HVlzJ58ZARne6mvrT521Guj9Q23vY7F3VbQBADRwCKKj2A0MlhD6mH h1Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=4syV9FIS6lt8aMO8mauvzf7SkGeQIk+uUxRl8nKAHpc=; b=NWRP0gkTjQcE3cRTOJYHqbhI3LYvw8PiCjB7P5CCKFkrEWq+E5BNf8wkdAno4y7HIL 4lfsCB6MVdTaOV+VAPbXpd08UKcVg4z5hSRg5blpK99uQVn32ZQhCJUHb3/j+az6j/h1 krIMrvAXVP+PrMpCrcwo33id5jWqV9B0oy5dJYf/lB6UtvylbPZvTZd7+JRsliyp6UEz v3up9adK9EJZhk0KBpwGDe5gSocQQjc7N5h3URYaLYHPJyZTxQwrk83SliM+UmnROc5j chMW/wUSi4EpJTIIY2/B1LS12F+JbGqMCWsPZbuwYwbmAUzxvhXzcTp+XBIrkqFFHPSV BOgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r18si2544506pfb.138.2018.01.30.07.01.25; Tue, 30 Jan 2018 07:01:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751934AbeA3O7T (ORCPT + 99 others); Tue, 30 Jan 2018 09:59:19 -0500 Received: from mga03.intel.com ([134.134.136.65]:6527 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbeA3O7S (ORCPT ); Tue, 30 Jan 2018 09:59:18 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2018 06:59:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,435,1511856000"; d="scan'208";a="14189710" Received: from linux.intel.com ([10.54.29.200]) by fmsmga008.fm.intel.com with ESMTP; 30 Jan 2018 06:59:17 -0800 Received: from [10.254.64.174] (kliang2-mobl1.ccr.corp.intel.com [10.254.64.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id B153E5802D1; Tue, 30 Jan 2018 06:59:16 -0800 (PST) Subject: Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read To: Jiri Olsa , Stephane Eranian Cc: Peter Zijlstra , Ingo Molnar , LKML , Arnaldo Carvalho de Melo , Thomas Gleixner , Andi Kleen References: <1517243373-355481-1-git-send-email-kan.liang@linux.intel.com> <20180130133917.GC29098@krava> From: "Liang, Kan" Message-ID: <6d708c09-52a7-a906-b651-b133a7b4f189@linux.intel.com> Date: Tue, 30 Jan 2018 09:59:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180130133917.GC29098@krava> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/30/2018 8:39 AM, Jiri Olsa wrote: > On Tue, Jan 30, 2018 at 01:16:39AM -0800, Stephane Eranian wrote: >> Hi, >> >> On Mon, Jan 29, 2018 at 8:29 AM, wrote: >>> >>> From: Kan Liang >>> >>> ------ >>> >>> Changes since V2: >>> - Refined the changelog >>> - Introduced specific read function for large PEBS. >>> The previous generic PEBS read function is confusing. >>> Disabled PMU in pmu::read() path for large PEBS. >>> Handled the corner case when reload_times == 0. >>> - Modified the parameter of intel_pmu_save_and_restart_reload() >>> Discarded local64_cmpxchg >>> - Added fixes tag >>> - Added WARN to handle reload_times == 0 || reload_val == 0 >>> >>> Changes since V1: >>> - Check PERF_X86_EVENT_AUTO_RELOAD before call >>> intel_pmu_save_and_restore() >> >> It is not yet clear to me why PERF_SAMPLE_PERIOD is not allowed >> with large PEBS. Large PEBS requires fixed period. So the kernel could >> make up the period from the event and store it in the sampling buffer. >> >> I tried using large PEBS recently, and despite trying different option >> combination of perf record, I was not able to get it to work. >> >> $ perf record -c 1 -e cpu/event=0xd1,umask=0x10,period=19936/pp >> --no-timestamp --no-period -a -C 0 >> >> But I was able to make this work with a much older kernel. >> >> Another annoyance I ran into is with perf record requiring -c period >> in order not to set >> PERF_SAMPLE_PERIOD in the event. >> >> If I do: >> perf record -c 1 -e cpu/event=0xd1,umask=0x10,period=19936/pp >> --no-timestamp --no-period -a -C 0 >> >> I get >> >> perf_event_attr: >> type 4 >> size 112 >> config 0x10d1 >> { sample_period, sample_freq } 199936 >> sample_type IP|TID|CPU >> >> But if I do: >> perf record -e cpu/event=0xd1,umask=0x10,period=19936/pp >> --no-timestamp --no-period -a -C 0 >> >> I get >> >> perf_event_attr: >> type 4 >> size 112 >> config 0x10d1 >> { sample_period, sample_freq } 199936 >> sample_type IP|TID|CPU|PERIOD >> >> Perf should check if all events have a period=, then it should not >> pass PERF_SAMPLE_PERIOD, even >> more so when only one event is defined. >> >> Also it does not seem to honor --no-period. > > yep, there's a bug in period=x term handling > we did not re/set the sample_type based on that > > attached patch fixes that for me, also takes into account > the --no/-period options > > jirka > > > --- > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c > index f251e824edac..907267206973 100644 > --- a/tools/perf/builtin-record.c > +++ b/tools/perf/builtin-record.c > @@ -1566,7 +1566,8 @@ static struct option __record_options[] = { > OPT_BOOLEAN_SET('T', "timestamp", &record.opts.sample_time, > &record.opts.sample_time_set, > "Record the sample timestamps"), > - OPT_BOOLEAN('P', "period", &record.opts.period, "Record the sample period"), > + OPT_BOOLEAN_SET('P', "period", &record.opts.period, &record.opts.period_set, > + "Record the sample period"), > OPT_BOOLEAN('n', "no-samples", &record.opts.no_samples, > "don't sample"), > OPT_BOOLEAN_SET('N', "no-buildid-cache", &record.no_buildid_cache, > diff --git a/tools/perf/perf.h b/tools/perf/perf.h > index 2357f4ccc9c7..cfe46236a5e5 100644 > --- a/tools/perf/perf.h > +++ b/tools/perf/perf.h > @@ -50,6 +50,7 @@ struct record_opts { > bool sample_time_set; > bool sample_cpu; > bool period; > + bool period_set; > bool running_time; > bool full_auxtrace; > bool auxtrace_snapshot_mode; > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c > index 66fa45198a11..ff359c9ece2e 100644 > --- a/tools/perf/util/evsel.c > +++ b/tools/perf/util/evsel.c > @@ -745,12 +745,14 @@ static void apply_config_terms(struct perf_evsel *evsel, > if (!(term->weak && opts->user_interval != ULLONG_MAX)) { > attr->sample_period = term->val.period; > attr->freq = 0; > + perf_evsel__reset_sample_bit(evsel, PERIOD); > } > break; > case PERF_EVSEL__CONFIG_TERM_FREQ: > if (!(term->weak && opts->user_freq != UINT_MAX)) { > attr->sample_freq = term->val.freq; > attr->freq = 1; > + perf_evsel__set_sample_bit(evsel, PERIOD); > } If we do so, some events could be in fixed mode without PERIOD set. Other events could be in freq mode with PERIOD set. That could be a problem for large PEBS. The PEBS buffer is shared among events. It doesn't support freq mode yet. Thanks, Kan > break; > case PERF_EVSEL__CONFIG_TERM_TIME: > @@ -969,9 +971,6 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts, > if (target__has_cpu(&opts->target) || opts->sample_cpu) > perf_evsel__set_sample_bit(evsel, CPU); > > - if (opts->period) > - perf_evsel__set_sample_bit(evsel, PERIOD); > - > /* > * When the user explicitly disabled time don't force it here. > */ > @@ -1073,6 +1072,14 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts, > apply_config_terms(evsel, opts, track); > > evsel->ignore_missing_thread = opts->ignore_missing_thread; > + > + /* The --period option takes the precedence. */ > + if (opts->period_set) { > + if (opts->period) > + perf_evsel__set_sample_bit(evsel, PERIOD); > + else > + perf_evsel__reset_sample_bit(evsel, PERIOD); > + } > } > > static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads) >