From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
maddy@linux.vnet.ibm.com, hemant@linux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/perf: Fix for core/nest imc call trace on cpuhotplug
Date: Mon, 25 Sep 2017 17:22:01 +0530 [thread overview]
Message-ID: <28e408f0-d773-6d91-9282-92aa65ef043e@linux.vnet.ibm.com> (raw)
In-Reply-To: <87r2v0d5zi.fsf@concordia.ellerman.id.au>
Hi mpe,
On Thursday 21 September 2017 10:04 AM, Michael Ellerman wrote:
> Anju T Sudhakar <anju@linux.vnet.ibm.com> writes:
>
>> Nest/core pmu units are enabled only when it is used. A reference count is
>> maintained for the events which uses the nest/core pmu units. Currently in
>> *_imc_counters_release function a WARN() is used for notification of any
>> underflow of ref count. Replace WARN() with a pr_info since it is an overkill.
> As discussed elsewhere this is not the right solution.
>
> If it's OK for the reference count to be negative, then we shouldn't
> print anything when it is.
>
> But I don't understand how it can be OK for the refcount to be negative.
> That means someone has a negative number of references to something?
>
> cheers
>
Scenario where this happens is in a stress test where perf session is
started, followed by offlining of all cpus in a given core. And finally
terminate the perf session.
So, in cpuhotplug offline path(ppc_core_imc_cpu_offline), function set
the ref->count to zero, if the current cpu which is about to offline is
the last cpu in a given core and make an OPAL call to disable the engine
in that core.
And on perf session termination, perf->destory
(core_imc_counters_release) will first decrement the ref->count for this
core and based on the ref->count value an opal call is made to disable
the core-imc engine.
Now, since cpuhotplug path already clears the ref->count for core and
disabled the engine, perf->destroy() decrementing again at event
termination make it negative which in turn fires the WARN_ON.
So we do prefer to remove the message as this wont happen in normal
operation and the core counters are working as expected.
I will send out a patch by removing the message asap.
Thanks,
Anju
next prev parent reply other threads:[~2017-09-25 11:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 17:32 [PATCH] powerpc/perf: Fix for core/nest imc call trace on cpuhotplug Anju T Sudhakar
2017-09-21 4:34 ` Michael Ellerman
2017-09-25 11:52 ` Anju T Sudhakar [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-10-04 6:50 Anju T Sudhakar
2017-10-05 9:50 ` Santosh Sivaraj
2017-10-05 9:51 ` 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=28e408f0-d773-6d91-9282-92aa65ef043e@linux.vnet.ibm.com \
--to=anju@linux.vnet.ibm.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=mpe@ellerman.id.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).