On Fri, 2012-09-07 at 21:10 +0200, Stephane Eranian wrote:
>
> That's true. I started modifying my code to implement your suggestion.
> We'll see how it goes. Then we would have to export that mux interval
> via sysfs for each PMU.
Indeed. Thanks!
--
To unsubscribe from this list: send the line
On Fri, Sep 7, 2012 at 9:08 PM, Peter Zijlstra wrote:
> On Fri, 2012-09-07 at 19:03 +0200, Stephane Eranian wrote:
>> I think having different intervals would be a good thing, especially for
>> uncore.
>> But now, I am wondering how this could work without too much overhead.
>> Looks like you're
On Fri, 2012-09-07 at 19:03 +0200, Stephane Eranian wrote:
> I think having different intervals would be a good thing, especially for
> uncore.
> But now, I am wondering how this could work without too much overhead.
> Looks like you're suggesting arming multiple hrtimers if multiple PMU are
> ove
On Fri, Sep 7, 2012 at 5:39 PM, Peter Zijlstra wrote:
> On Fri, 2012-09-07 at 16:29 +0200, Stephane Eranian wrote:
>> @@ -148,6 +148,15 @@ static LIST_HEAD(pmus);
>> static DEFINE_MUTEX(pmus_lock);
>> static struct srcu_struct pmus_srcu;
>>
>> +struct perf_cpu_hrtimer {
>> + struct hrtimer
On Fri, 2012-09-07 at 16:29 +0200, Stephane Eranian wrote:
Style nit:
> + if (h->active)
> + list_for_each_entry_safe(cpuctx, tmp, head, rotation_list)
> + rotations += perf_rotate_context(cpuctx);
> + if (!hrtimer_callback_running(hr))
> + __
On Fri, 2012-09-07 at 16:29 +0200, Stephane Eranian wrote:
> @@ -148,6 +148,15 @@ static LIST_HEAD(pmus);
> static DEFINE_MUTEX(pmus_lock);
> static struct srcu_struct pmus_srcu;
>
> +struct perf_cpu_hrtimer {
> + struct hrtimer hrtimer;
> + int active;
> +};
> +
> +static DEFINE_PE
The current scheme of using the timer tick was fine
for per-thread events. However, it was causing
bias issues in system-wide mode (including for
uncore PMUs). Event groups would not get their
fair share of runtime on the PMU. With tickless
kernels, if a core is idle there is no timer tick,
and thu
7 matches
Mail list logo
