Received: by 10.223.176.5 with SMTP id f5csp4367568wra; Tue, 30 Jan 2018 06:20:59 -0800 (PST) X-Google-Smtp-Source: AH8x225iQjnBlmS4V8EXxcrIvbA5blaensGZ2yjkARC4B8wJh/xwbsAFJoQQOG5rRzDP8kekaI73 X-Received: by 10.101.76.75 with SMTP id l11mr23695955pgr.224.1517322059837; Tue, 30 Jan 2018 06:20:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517322059; cv=none; d=google.com; s=arc-20160816; b=wokUfVKw1C8kY/TpI+vYbCIcySKt4PO5HyG9c8UcqxQEW9CAkpL2a4PkUpC8jBPj/W vz02vLOnGB/raRHFOgKSfFImbXVmWQan6A8+/8yHpLN9ei4BSPwKQWAMMU0G/Ri7N13p NK0vNktTBJDwlrDYCea27kTQhWcE6KctVh+UJP2UpagKDum3iwjGEBseEvM8Jh5IgJEx KAoDhOdrrlq4AVDwqlH7eYRqLALYcEGxXddozTbM3lzo/qatiwjVL++zkwZNoEH/JGHN pAreYAGKm7bVReXi3A0Ox2C2rUZsVv4AMqbmuKcwnRENYWgnIb6fF6RLInVTN0cjyD7H Wt0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=y+g9IfXx8SoL6baOQdnXZCKAnPnjU8Un9kyAGXaXiFY=; b=jvKDIEPiVS05fsF5tHBHxkOTJ/1IvzzlgnT7vdJ5jmjuYpWhp3rZR0hb6N/GELUD9S VGrD6BcyFWL1NweAg3woPDtrIRSP6wZx7DQ9UfdShBlm15h29mhertC4zMJpbd8QBPu7 sb5fn6KXH2iXzYlqvCQBF/EbeWDeT++5mJqJYsj+w7sBNLXO8w53rgaYqGXtG9uIfAto se86HdXeayyL13p397NAGKWoSfaschelxs2GJKS8b4jx8lVzIGZU7ZVphRC46XBsX1Gw vtcBsN1tjMh9en0/h6PaRC7o8qqfaF2M+E69tA2Uivj9jOoov/x0Zi9grTGd52x8kQ9D e3zQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i128si9236886pgd.201.2018.01.30.06.20.45; Tue, 30 Jan 2018 06:20:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063AbeA3Njl (ORCPT + 99 others); Tue, 30 Jan 2018 08:39:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51444 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751674AbeA3Njk (ORCPT ); Tue, 30 Jan 2018 08:39:40 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3890D62EA8; Tue, 30 Jan 2018 13:39:40 +0000 (UTC) Received: from krava (unknown [10.43.17.162]) by smtp.corp.redhat.com (Postfix) with SMTP id 652267E0B1; Tue, 30 Jan 2018 13:39:37 +0000 (UTC) Date: Tue, 30 Jan 2018 14:39:17 +0100 From: Jiri Olsa To: Stephane Eranian Cc: kan.liang@linux.intel.com, Peter Zijlstra , Ingo Molnar , LKML , Arnaldo Carvalho de Melo , Thomas Gleixner , Andi Kleen Subject: Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read Message-ID: <20180130133917.GC29098@krava> References: <1517243373-355481-1-git-send-email-kan.liang@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 30 Jan 2018 13:39:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); } 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)