Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301530 > unrolled thread

Re: [PATCH v4 05/12] arm-cci: PMU: Add support for transactions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 05/12] arm-cci: PMU: Add support for transactions Peter Zijlstra <peterz@infradead.org> - 2016-01-05 14:40 +0100
    Re: [PATCH v4 05/12] arm-cci: PMU: Add support for transactions "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2016-01-05 14:50 +0100
      Re: [PATCH v4 05/12] arm-cci: PMU: Add support for transactions Peter Zijlstra <peterz@infradead.org> - 2016-01-05 16:00 +0100

#1301530 — Re: [PATCH v4 05/12] arm-cci: PMU: Add support for transactions

On Mon, Dec 21, 2015 at 10:55:29AM +0000, Suzuki K. Poulose wrote:
> Thanks for that hint. Here is what I cam up with. We don't reschedule
> the events, all we need to do is group the writes to the counters. Hence
> we could as well add a flag for those events which need programming
> and perform the write in pmu::pmu_enable().

I'm still somewhat confused..

> Grouping the writes to counters can ammortise the cost of the operation
> on PMUs where it is expensive (e.g, CCI-500).

This rationale makes me think you want to reduce the number of counter
writes, not batch them per-se.

So why are you unconditionally writing all counters, instead of only
those that changed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1301541

On 05/01/16 13:37, Peter Zijlstra wrote:
> On Mon, Dec 21, 2015 at 10:55:29AM +0000, Suzuki K. Poulose wrote:
>> Thanks for that hint. Here is what I cam up with. We don't reschedule
>> the events, all we need to do is group the writes to the counters. Hence
>> we could as well add a flag for those events which need programming
>> and perform the write in pmu::pmu_enable().
>
> I'm still somewhat confused..
>
>> Grouping the writes to counters can ammortise the cost of the operation
>> on PMUs where it is expensive (e.g, CCI-500).
>
> This rationale makes me think you want to reduce the number of counter
> writes, not batch them per-se.
>
> So why are you unconditionally writing all counters, instead of only
> those that changed?
>

The ARM CCI PMU reprograms all the counters with a specific value (2^31)
to account for high interrupt latencies in recording the counters that
overflowed. So, pmu_stop() updates the counter and pmu_start() resets
the counter to the above value, always.

Now, writing to a single counter requires

1) Stopping and disabling all the counters in HW (So that step 3 doesn't
interfere with the other counters)
2) Program the target counter with invalid event and enable the counter.
3) Enable the PMU and then write to the counter.
4) Reset everything back to normal.


So, the approach here is to delay the writes to the counters as much as possible
and batch them. So that we don't have to repeat steps 1 & 4 for every single
counter.

Does it help ?

Thanks
Suzuki


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301582

On Tue, Jan 05, 2016 at 01:43:30PM +0000, Suzuki K. Poulose wrote:
> On 05/01/16 13:37, Peter Zijlstra wrote:
> >On Mon, Dec 21, 2015 at 10:55:29AM +0000, Suzuki K. Poulose wrote:
> >>Thanks for that hint. Here is what I cam up with. We don't reschedule
> >>the events, all we need to do is group the writes to the counters. Hence
> >>we could as well add a flag for those events which need programming
> >>and perform the write in pmu::pmu_enable().
> >
> >I'm still somewhat confused..
> >
> >>Grouping the writes to counters can ammortise the cost of the operation
> >>on PMUs where it is expensive (e.g, CCI-500).
> >
> >This rationale makes me think you want to reduce the number of counter
> >writes, not batch them per-se.
> >
> >So why are you unconditionally writing all counters, instead of only
> >those that changed?
> >
> 
> The ARM CCI PMU reprograms all the counters with a specific value (2^31)
> to account for high interrupt latencies in recording the counters that
> overflowed. So, pmu_stop() updates the counter and pmu_start() resets
> the counter to the above value, always.
> 
> Now, writing to a single counter requires
> 
> 1) Stopping and disabling all the counters in HW (So that step 3 doesn't
> interfere with the other counters)
> 2) Program the target counter with invalid event and enable the counter.
> 3) Enable the PMU and then write to the counter.
> 4) Reset everything back to normal.
> 
> 
> So, the approach here is to delay the writes to the counters as much as possible
> and batch them. So that we don't have to repeat steps 1 & 4 for every single
> counter.
> 
> Does it help ?

Yes, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web