All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>,
	mpe@ellerman.id.au, LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org, ego@linux.vnet.ibm.com,
	bsingharora@gmail.com, Anton Blanchard <anton@samba.org>,
	sukadev@linux.vnet.ibm.com, mikey@neuling.org,
	stewart@linux.vnet.ibm.com, dja@axtens.net, eranian@google.com,
	hemant@linux.vnet.ibm.com, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support
Date: Mon, 15 May 2017 13:06:09 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1705151250540.2027@nanos> (raw)
In-Reply-To: <f8972c0c-11db-fd43-09a3-200b90a34d3b@linux.vnet.ibm.com>

On Mon, 15 May 2017, Madhavan Srinivasan wrote:
> On Wednesday 10 May 2017 05:39 PM, Thomas Gleixner wrote:
> > On Thu, 4 May 2017, Anju T Sudhakar wrote:
> > > +	/*
> > > +	 * Update the cpumask with the target cpu and
> > > +	 * migrate the context if needed
> > > +	 */
> > > +	if (target >= 0 && target <= nr_cpu_ids) {
> > > +		cpumask_set_cpu(target, &nest_imc_cpumask);
> > > +		nest_change_cpu_context(cpu, target);
> > > +	}
> > What disables the perf context if this was the last CPU on the node?
> 
> My bad. i did not understand this. Is this regarding the updates
> of the "flags" in the perf_event and hw_perf_event structs?

Sorry, there is nothing to understand. It was me misreading it.

> > > +static int nest_pmu_cpumask_init(void)
> > > +{
> > > +	const struct cpumask *l_cpumask;
> > > +	int cpu, nid;
> > > +	int *cpus_opal_rc;
> > > +
> > > +	if (!cpumask_empty(&nest_imc_cpumask))
> > > +		return 0;
> > What's that for? Paranoia engineering?
> 
> No.  The idea here is to generate the cpu_mask attribute
> field only for the first "nest" pmu and use the same
> for other "nest" units.

Why is nest_pmu_cpumask_init() called more than once? If it is then you
should have a proper flag marking it initialiazed rather than making a
completely obscure check for a cpu mask. That check could be empty for the
second invocation when the first invocation fails.

> > But this whole function is completely overengineered. If you make that
> > nest_init() part of the online function then this works also for nodes
> > which come online later and it simplifies to:
> > 
> > static int ppc_nest_imc_cpu_online(unsigned int cpu)
> > {
> > 	const struct cpumask *l_cpumask;
> > 	static struct cpumask tmp_mask;
> > 	int res;
> > 
> > 	/* Get the cpumask of this node */
> > 	l_cpumask = cpumask_of_node(cpu_to_node(cpu));
> > 
> > 	/*
> > 	 * If this is not the first online CPU on this node, then IMC is
> > 	 * initialized already.
> > 	 */
> > 	if (cpumask_and(&tmp_mask, l_cpumask, &nest_imc_cpumask))
> > 		return 0;
> > 
> > 	/*
> > 	 * If this fails, IMC is not usable.
> > 	 *
> > 	 * FIXME: Add a understandable comment what this actually does
> > 	 * and why it can fail.
> > 	 */
> > 	res = opal_imc_counters_stop(OPAL_IMC_COUNTERS_NEST);
> > 	if (res)
> > 		return res;
> > 
> > 	/* Make this CPU the designated target for counter collection */
> > 	cpumask_set_cpu(cpu, &nest_imc_cpumask);
> > 	nest_change_cpu_context(-1, cpu);
> > 	return 0;
> > }
> > 
> > static int nest_pmu_cpumask_init(void)
> > {
> > 	return cpuhp_setup_state(CPUHP_AP_PERF_POWERPC_NEST_ONLINE,
> > 				 "perf/powerpc/imc:online",
> > 				 ppc_nest_imc_cpu_online,
> > 				 ppc_nest_imc_cpu_offline);
> > }
> > 
> > Hmm?
> 
> Yes this make sense. But we need to first designate a cpu in each
> chip at init setup and use opal api to disable the engine in the same.
> So probably, after cpuhp_setup_state, can we do that?

Errm. That's what ppc_nest_imc_cpu_online() does.

It checks whether this is the first online cpu on a node and if yes, it
calls opal_imc_counters_stop() and sets that cpu in nest_imc_cpumask.

cpuhp_setup_state() invokes the callback on each online CPU. Seo evrything
is set up proper after that.

Thanks,

	tglx

  reply	other threads:[~2017-05-15 11:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 14:19 [PATCH v8 00/10] IMC Instrumentation Support Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 01/10] powerpc/powernv: Data structure and macros definitions for IMC Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 02/10] powerpc/powernv: Autoload IMC device driver module Anju T Sudhakar
2017-05-11  7:49   ` Stewart Smith
2017-05-12  4:36     ` Madhavan Srinivasan
2017-05-04 14:19 ` [PATCH v8 03/10] powerpc/powernv: Detect supported IMC units and its events Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 04/10] powerpc/perf: Add generic IMC pmu groupand event functions Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support Anju T Sudhakar
2017-05-08 14:12   ` Daniel Axtens
2017-05-09  6:10     ` Madhavan Srinivasan
2017-05-12  2:18       ` Stewart Smith
2017-05-12  3:33         ` Michael Ellerman
2017-05-12  3:50           ` Madhavan Srinivasan
2017-05-12  3:41         ` Madhavan Srinivasan
2017-05-09 10:54     ` Anju T Sudhakar
2017-05-10  5:21     ` Michael Ellerman
2017-05-10 12:09   ` Thomas Gleixner
2017-05-10 23:40     ` Stephen Rothwell
2017-05-11  8:39       ` Thomas Gleixner
2017-05-15 10:12     ` Madhavan Srinivasan
2017-05-15 11:06       ` Thomas Gleixner [this message]
2017-05-04 14:19 ` [PATCH v8 06/10] powerpc/powernv: Core IMC events detection Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging Anju T Sudhakar
2017-05-17  7:57   ` Stewart Smith
2017-05-04 14:19 ` [PATCH v8 08/10] powerpc/powernv: Thread IMC events detection Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 09/10] powerpc/perf: Thread IMC PMU functions Anju T Sudhakar
2017-05-04 14:19 ` [PATCH v8 10/10] powerpc/perf: Thread imc cpuhotplug support Anju T Sudhakar

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=alpine.DEB.2.20.1705151250540.2027@nanos \
    --to=tglx@linutronix.de \
    --cc=anju@linux.vnet.ibm.com \
    --cc=anton@samba.org \
    --cc=bsingharora@gmail.com \
    --cc=dja@axtens.net \
    --cc=ego@linux.vnet.ibm.com \
    --cc=eranian@google.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mikey@neuling.org \
    --cc=mpe@ellerman.id.au \
    --cc=peterz@infradead.org \
    --cc=stewart@linux.vnet.ibm.com \
    --cc=sukadev@linux.vnet.ibm.com \
    /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.