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

Groups > linux.kernel > #1393127 > unrolled thread

Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

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 2/4] perf/x86/mbm: Store bytes counted for mbm during  recycle Peter Zijlstra <peterz@infradead.org> - 2016-05-03 09:50 +0200
    Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during  recycle Vikas Shivappa <vikas.shivappa@intel.com> - 2016-05-04 02:10 +0200

#1393127 — Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

On Mon, Apr 25, 2016 at 02:12:09PM -0700, Vikas Shivappa wrote:


> >start:
> >      prev_count = read_hw_counter();
> 
> I am assuming this means we keep the prev_count when event is initialized.
> This is done in the mbm_init which calls update_sample with first parameter
> set to true..

No, when pmu::start() is called.

> >read:
> >      do {
> >              prev = prev_count;
> >              cur_val = read_hw_counter();
> >              delta = cur_val - prev;
> >      } while (local_cmpxchg(&prev_count, prev, cur_val) != prev);
> >      count += delta;

And this you do on pmu::{stop,read}()

> the update_sample does the work to compute the delta and add the delta to
> total_bytes..  it has all the code except for the while loop.

No, no, no, you add rc_count and st_count and generally make a huge mess
of things. The above needs none of that.

Because the above only cares about deltas against the hw counter (as per
prev_count). Therefore count can be an absolute value that carries all
your history as per rc_count, and you don't need st_count because per
prev_count you don't care about the absolute value of the hw counter.

[toc] | [next] | [standalone]

#1393869

On Tue, 3 May 2016, Peter Zijlstra wrote:

> On Mon, Apr 25, 2016 at 02:12:09PM -0700, Vikas Shivappa wrote:
>
>
>>> start:
>>>      prev_count = read_hw_counter();
>>
>> I am assuming this means we keep the prev_count when event is initialized.
>> This is done in the mbm_init which calls update_sample with first parameter
>> set to true..
>
> No, when pmu::start() is called.
>
>>> read:
>>>      do {
>>>              prev = prev_count;
>>>              cur_val = read_hw_counter();
>>>              delta = cur_val - prev;
>>>      } while (local_cmpxchg(&prev_count, prev, cur_val) != prev);
>>>      count += delta;
>
> And this you do on pmu::{stop,read}()

Ok. We have same function for del and stop in cqm. Also we do count for cqm..
So we end up reading the 
counter every sched_out. We avoided this to not have the overhead. Also we have 
the overflow of mbm counters on top of this.

But I see how this can be done using the update_sample as the wrapper.

start:
   prev = update_sample(rmid) // reads the counter and takes care of overflow.

Basically replace the hw_counter call with the update_sample and also do the 
part thats done in the read in the overflow timer as well..

Will send an update.

Thanks,
Vikas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web