All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pawel Moll <pawel.moll@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"eranian@google.com" <eranian@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"acme@kernel.org" <acme@kernel.org>,
	"dsahern@gmail.com" <dsahern@gmail.com>,
	"fweisbec@gmail.com" <fweisbec@gmail.com>,
	"jolsa@redhat.com" <jolsa@redhat.com>,
	"namhyung@gmail.com" <namhyung@gmail.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"sonnyrao@chromium.org" <sonnyrao@chromium.org>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"vincent.weaver@maine.edu" <vincent.weaver@maine.edu>
Subject: Re: [RFC][PATCH 2/2] perf: Add per event clockid support
Date: Fri, 20 Feb 2015 15:28:49 +0000	[thread overview]
Message-ID: <1424446129.6259.5.camel@arm.com> (raw)
In-Reply-To: <20150220143754.852733868@infradead.org>

On Fri, 2015-02-20 at 14:29 +0000, Peter Zijlstra wrote:
> The below patch makes the distinction between these two cases by
> adding perf_event_clock() which is used for the second case. It
> further makes this configurable on a per-event basis, but adds a few
> sanity checks such that we cannot combine events with different clocks
> in confusing ways.

The idea works for me (obviously :-)

> And since we then have per-event configurability we might as well
> retain the 'legacy' behaviour as a default.

Don't mind that at all.

> @@ -334,8 +335,7 @@ struct perf_event_attr {
>  	 */
>  	__u32	sample_stack_user;
>  
> -	/* Align to u64. */
> -	__u32	__reserved_2;
> +	__u32	clockid;

I thought about it, but was sort-of-afraid to propose it :-)

Now, one thing I'm not 100% sure about it is it being unsigned, as
clockid_t is signed for a reason (negative values have meaning - eg.
dynamic clocks, which could be useful in some circumstances). Of course
casting could be an answer, but is there any reason not to make it
__s32?

> +		default:
> +			/* XXX add: clock_id_valid() && clock_gettime_ns() ? */
> +			err = -EINVAL;
> +			goto err_alloc;
> +		}

If you asked me, I'd say -EINVAL, no default.

Cheers!

Pawel


  reply	other threads:[~2015-02-20 15:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20 14:29 [RFC][PATCH 0/2] On perf and clocks Peter Zijlstra
2015-02-20 14:29 ` [RFC][PATCH 1/2] time: Add ktime_get_mono_raw_fast_ns() Peter Zijlstra
2015-02-20 19:49   ` John Stultz
2015-02-20 20:11     ` Peter Zijlstra
2015-03-17 11:24     ` Peter Zijlstra
2015-03-18 19:48       ` John Stultz
2015-02-20 14:29 ` [RFC][PATCH 2/2] perf: Add per event clockid support Peter Zijlstra
2015-02-20 15:28   ` Pawel Moll [this message]
2015-02-20 16:01     ` Peter Zijlstra
2015-02-23  8:13   ` Adrian Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1424446129.6259.5.camel@arm.com \
    --to=pawel.moll@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@gmail.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sonnyrao@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.weaver@maine.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.