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

Groups > linux.kernel > #1383391 > unrolled thread

Re: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL client uncore

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 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore Thomas Gleixner <tglx@linutronix.de> - 2016-04-20 15:40 +0200
    RE: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore "Liang, Kan" <kan.liang@intel.com> - 2016-04-20 16:00 +0200
      RE: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore Thomas Gleixner <tglx@linutronix.de> - 2016-04-20 17:00 +0200
        RE: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore "Liang, Kan" <kan.liang@intel.com> - 2016-04-20 17:30 +0200
          RE: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore Thomas Gleixner <tglx@linutronix.de> - 2016-04-21 10:10 +0200
            RE: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore "Liang, Kan" <kan.liang@intel.com> - 2016-04-21 14:00 +0200
      Re: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL  client uncore Andi Kleen <ak@linux.intel.com> - 2016-04-20 18:40 +0200

#1383391 — Re: [PATCH 1/1] perf/x86/intel/uncore: Add support for Intel SKL client uncore

On Fri, 15 Apr 2016, kan.liang@intel.com wrote:
> +static void skl_uncore_msr_init_box(struct intel_uncore_box *box)
> +{
> +	if (box->pmu->pmu_idx == 0) {
> +		wrmsrl(SKL_UNC_PERF_GLOBAL_CTL,
> +			SNB_UNC_GLOBAL_CTL_EN | SKL_UNC_GLOBAL_CTL_CORE_ALL);
> +	}
> +}
> +
> +static void skl_uncore_msr_enable_box(struct intel_uncore_box *box)
> +{
> +	wrmsrl(SKL_UNC_PERF_GLOBAL_CTL,
> +		SNB_UNC_GLOBAL_CTL_EN | SKL_UNC_GLOBAL_CTL_CORE_ALL);
> +}
> +
> +static void skl_uncore_msr_disable_box(struct intel_uncore_box *box)
> +{
> +	wrmsrl(SKL_UNC_PERF_GLOBAL_CTL, 0);
> +}
> +
> +static void skl_uncore_msr_exit_box(struct intel_uncore_box *box)
> +{
> +	if (box->pmu->pmu_idx == 0)
> +		wrmsrl(SKL_UNC_PERF_GLOBAL_CTL, 0);
> +}

The above looks broken.

init() enables the uncore machinery on the node it is running on.

start() enables the uncore machinery on the node it is running on.

stop() disables the uncore machinery on the node it is running on.

So what happens in the following case:

   start(event(box0), node0)

   start(event(box1), node0)

   stop(event(box1), node0)

The stop of the box1 events disables the whole machinery on that node and
therefor the box0 event is wreckaged as well. Hmm?

Thanks,

	tglx

[toc] | [next] | [standalone]

#1383411

 
> On Fri, 15 Apr 2016, kan.liang@intel.com wrote:
> > +static void skl_uncore_msr_init_box(struct intel_uncore_box *box) {
> > +	if (box->pmu->pmu_idx == 0) {
> > +		wrmsrl(SKL_UNC_PERF_GLOBAL_CTL,
> > +			SNB_UNC_GLOBAL_CTL_EN |
> SKL_UNC_GLOBAL_CTL_CORE_ALL);
> > +	}
> > +}
> > +
> > +static void skl_uncore_msr_enable_box(struct intel_uncore_box *box) {
> > +	wrmsrl(SKL_UNC_PERF_GLOBAL_CTL,
> > +		SNB_UNC_GLOBAL_CTL_EN |
> SKL_UNC_GLOBAL_CTL_CORE_ALL); }
> > +
> > +static void skl_uncore_msr_disable_box(struct intel_uncore_box *box)
> > +{
> > +	wrmsrl(SKL_UNC_PERF_GLOBAL_CTL, 0);
> > +}
> > +
> > +static void skl_uncore_msr_exit_box(struct intel_uncore_box *box) {
> > +	if (box->pmu->pmu_idx == 0)
> > +		wrmsrl(SKL_UNC_PERF_GLOBAL_CTL, 0); }
> 
> The above looks broken.
> 
> init() enables the uncore machinery on the node it is running on.
> 
> start() enables the uncore machinery on the node it is running on.
> 
> stop() disables the uncore machinery on the node it is running on.
> 
> So what happens in the following case:
> 
>    start(event(box0), node0)
> 
>    start(event(box1), node0)
> 
>    stop(event(box1), node0)
> 
> The stop of the box1 events disables the whole machinery on that node and
> therefor the box0 event is wreckaged as well. Hmm?
> 

Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in enable_event?
If it's cleared, we can reset it there. The drawback is that there will be an extra
rdmsrl and a possible wrmsrl. 

Thanks,
Kan

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

#1383473

On Wed, 20 Apr 2016, Liang, Kan wrote:
> > The stop of the box1 events disables the whole machinery on that node and
> > therefor the box0 event is wreckaged as well. Hmm?
> > 
> Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in enable_event?  If it's
> cleared, we can reset it there. The drawback is that there will be an extra
> rdmsrl and a possible wrmsrl.

Well, that does not buy anything as you cannot disable the thing at all,
unless you have refcounting. And that refcounting needs to be in the 'type'
struct and that would probably be some real pain to implement.

The question is whether we need enable/disable at all. If the type is
initialized we enable it and on exit we disable it. Ditto on cpu hotplug -
which is also used for init to enable all nodes.

So if there is no drawback in letting the thing enabled if no events are
armed, then we really can do w/o the enable/disable_box callbacks.

Thanks,

	tglx

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

#1383492

> On Wed, 20 Apr 2016, Liang, Kan wrote:
> > > The stop of the box1 events disables the whole machinery on that
> > > node and therefor the box0 event is wreckaged as well. Hmm?
> > >
> > Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in enable_event?
> > If it's cleared, we can reset it there. The drawback is that there
> > will be an extra rdmsrl and a possible wrmsrl.
> 
> Well, that does not buy anything as you cannot disable the thing at all, unless
> you have refcounting. And that refcounting needs to be in the 'type'
> struct and that would probably be some real pain to implement.
> 
> The question is whether we need enable/disable at all. If the type is
> initialized we enable it and on exit we disable it. Ditto on cpu hotplug - which
> is also used for init to enable all nodes.
> 
> So if there is no drawback in letting the thing enabled if no events are armed,
> then we really can do w/o the enable/disable_box callbacks.
> 

There is no drawback in letting the thing enabled, but PERF_GLOBAL_CTL could
be disabled after Package C7. I add the enable/disable thing to try to
workaround it.
I once did the test on a SKL laptop. If the machine goes idle for a while, then the
uncore counter will always return 0. For fixing it, we have to re-enable
PERF_GLOBAL_CTL.
I think I made a typo in previous reply. I mean we can check it or just force rewrite
the PERF_GLOBAL_CTL in enable_box. We don't need disable_box since there is
no drawback in letting the thing enabled.
The HSW and BDW client also have similar errata. If it's OK for you, I will send
another patch for them.

Thanks,
Kan

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

#1383920

On Wed, 20 Apr 2016, Liang, Kan wrote:
> > On Wed, 20 Apr 2016, Liang, Kan wrote:
> > > > The stop of the box1 events disables the whole machinery on that
> > > > node and therefor the box0 event is wreckaged as well. Hmm?
> > > >
> > > Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in enable_event?
> > > If it's cleared, we can reset it there. The drawback is that there
> > > will be an extra rdmsrl and a possible wrmsrl.
> > 
> > Well, that does not buy anything as you cannot disable the thing at all, unless
> > you have refcounting. And that refcounting needs to be in the 'type'
> > struct and that would probably be some real pain to implement.
> > 
> > The question is whether we need enable/disable at all. If the type is
> > initialized we enable it and on exit we disable it. Ditto on cpu hotplug - which
> > is also used for init to enable all nodes.
> > 
> > So if there is no drawback in letting the thing enabled if no events are armed,
> > then we really can do w/o the enable/disable_box callbacks.
> > 
> There is no drawback in letting the thing enabled, but PERF_GLOBAL_CTL could
> be disabled after Package C7. I add the enable/disable thing to try to
> workaround it.

I don't see how that solves it. If a counter is active, then C7 will stop it
and you wont get anything useful from it after returning from C7. Or does an
active counter prevent C7?

> I once did the test on a SKL laptop. If the machine goes idle for a while,
> then the uncore counter will always return 0. For fixing it, we have to
> re-enable PERF_GLOBAL_CTL.

Hmm, but that does only help for new events after returning from C7, right?

> I think I made a typo in previous reply. I mean we can check it or just
> force rewrite the PERF_GLOBAL_CTL in enable_box. We don't need disable_box
> since there is no drawback in letting the thing enabled.

Sure, but then you can just unconditionally enable it. IOW, leave the enable
callback as is.

Thanks,

	tglx

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

#1384128

> 
> On Wed, 20 Apr 2016, Liang, Kan wrote:
> > > On Wed, 20 Apr 2016, Liang, Kan wrote:
> > > > > The stop of the box1 events disables the whole machinery on that
> > > > > node and therefor the box0 event is wreckaged as well. Hmm?
> > > > >
> > > > Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in
> enable_event?
> > > > If it's cleared, we can reset it there. The drawback is that there
> > > > will be an extra rdmsrl and a possible wrmsrl.
> > >
> > > Well, that does not buy anything as you cannot disable the thing at
> > > all, unless you have refcounting. And that refcounting needs to be in the
> 'type'
> > > struct and that would probably be some real pain to implement.
> > >
> > > The question is whether we need enable/disable at all. If the type
> > > is initialized we enable it and on exit we disable it. Ditto on cpu
> > > hotplug - which is also used for init to enable all nodes.
> > >
> > > So if there is no drawback in letting the thing enabled if no events
> > > are armed, then we really can do w/o the enable/disable_box callbacks.
> > >
> > There is no drawback in letting the thing enabled, but PERF_GLOBAL_CTL
> > could be disabled after Package C7. I add the enable/disable thing to
> > try to workaround it.
> 
> I don't see how that solves it. If a counter is active, then C7 will stop it and
> you wont get anything useful from it after returning from C7. Or does an
> active counter prevent C7?

Right, the workaround doesn't cover all cases. It helps for the new events
and the cases that monitoring a busy system. A busy system means it never
enter C7 during the counting.
I will mention it in the changelog of V2. 

> 
> > I once did the test on a SKL laptop. If the machine goes idle for a
> > while, then the uncore counter will always return 0. For fixing it, we
> > have to re-enable PERF_GLOBAL_CTL.
> 
> Hmm, but that does only help for new events after returning from C7, right?

Yes.

> 
> > I think I made a typo in previous reply. I mean we can check it or
> > just force rewrite the PERF_GLOBAL_CTL in enable_box. We don't need
> > disable_box since there is no drawback in letting the thing enabled.
> 
> Sure, but then you can just unconditionally enable it. IOW, leave the enable
> callback as is.

Will do that in V2.

Thanks,
Kan

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

#1383556

> Right. How about check the SKL_UNC_PERF_GLOBAL_CTL in enable_event?
> If it's cleared, we can reset it there. The drawback is that there will be an extra
> rdmsrl and a possible wrmsrl. 

It's better to not rely on register state for this. There are a variety
of user space tools that manipulate the uncore MSRs through /dev/*/msr
So better keep software state. Software state is also much faster than
reading MSRs.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web