From: Raghavendra Rao Ananta <rananta@codeaurora.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, psodagud@codeaurora.org,
tsoni@codeaurora.org, skannan@codeaurora.org
Subject: Re: [PATCH 1/1] perf: Add CPU hotplug support for events
Date: Fri, 16 Feb 2018 17:48:21 -0800 [thread overview]
Message-ID: <aee872be-c34d-729b-575d-df488a46f2cf@codeaurora.org> (raw)
In-Reply-To: <20180216203953.GL25201@hirez.programming.kicks-ass.net>
On 02/16/2018 12:39 PM, Peter Zijlstra wrote:
> On Fri, Feb 16, 2018 at 10:06:29AM -0800, Raghavendra Rao Ananta wrote:
>>> No this is absolutely disguisting. You can simply keep the events in the
>>> dead CPU's context. It's really not that hard.
>> Keeping the events in the dead CPU's context was also an idea that we had.
>> However, detaching that event from the PMU when the CPU is offline would be
>> a pain. Consider the scenario in which an event is about to be destroyed
>> when the CPU is offline (yet still attached to the CPU). During it's
>> destruction, a cross-cpu call is made (from perf_remove_from_context()) to
>> the offlined CPU to detach the event from the CPU's PMU. As the CPU is
>> offline, that would not be possible, and again a separate logic has to be
>> written for cleaning up the events whose CPUs are offlined.
>
> That is actually really simple to deal with. The real problems are with
> semantics, is an event enabled when the CPU is dead? Can you
> disable/enable an event on a dead CPU.
>
> The below patch (_completely_ untested) should do most of it, but needs
> help with the details. I suspect we want to allow enable/disable on
> events that are on a dead CPU, and equally I think we want to account
> the time an enabled event spends on a dead CPU to go towards the
> 'enabled' bucket.
I've gone through your diff, and it gave me a hint of similar texture
what we are trying to do (except for maintaining an offline event list).
Nevertheless, I tried to test your patch. I created an hw event, and
tried to offline the CPU in parallel, and I immediately hit a watchdog
soft lockup bug! Tried the same this by first switching off the CPU
(without any event created), and I hit into similar issue. I am sure we
can fix it, but apart from the "why we are doing hotplug?" question, was
was there specifically any issue with our patch?
>
>>> Also, you _still_ don't explain why you care about dead CPUs.
>>>
I wanted to understand, if we no longer care about hotplugging of CPUs,
then why do we still have exported symbols such as cpu_up() and
cpu_down()? Moreover, we also have the hotplug interface exposed to
users-space as well (through sysfs). As long as these interfaces exist,
there's always a potential chance of bringing the CPU up/down. Can you
please clear this thing up for me?
-- Raghavendra
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-02-17 1:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 23:01 [PATCH 0/1] " Raghavendra Rao Ananta
2018-02-15 23:01 ` [PATCH 1/1] " Raghavendra Rao Ananta
2018-02-16 8:21 ` Peter Zijlstra
2018-02-16 18:06 ` Raghavendra Rao Ananta
2018-02-16 20:39 ` Peter Zijlstra
2018-02-17 1:48 ` Raghavendra Rao Ananta [this message]
2018-02-19 9:11 ` Peter Zijlstra
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=aee872be-c34d-729b-575d-df488a46f2cf@codeaurora.org \
--to=rananta@codeaurora.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=psodagud@codeaurora.org \
--cc=skannan@codeaurora.org \
--cc=tsoni@codeaurora.org \
/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
Powered by JetHome