From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/2] arm64: kernel: perf: add pmu CPU PM notifier
Date: Thu, 12 Mar 2015 10:27:33 +0000 [thread overview]
Message-ID: <20150312102733.GC18414@red-moon> (raw)
In-Reply-To: <7hh9try12u.fsf@deeprootsystems.com>
[Cc'ing Dave]
On Wed, Mar 11, 2015 at 04:02:17PM +0000, Kevin Hilman wrote:
> Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> writes:
>
> > When a CPU is being profiled through PMU events and it enters suspend
> > or idle states, the PMU registers content can be lost, which means that
> > counters that were relied upon on power down entry are reset on power
> > up to values that are incosistent with the profile session.
> >
> > This patch adds a CPU PM notifier to arm64 perf code, that detects
> > on entry if events are being monitored, and if so, it returns
> > failure to the CPU PM notification chain, causing the suspend
> > thread or the idle thread to abort power down, therefore preventing
> > registers content loss.
> >
> > By triggering CPU PM notification failure this patch prevents
> > suspending a system if the suspend thread is being profiled and
> > it also prevents entering idle deep states on cores that have profile
> > events in use, somehow limiting power management capabilities when
> > there are active perf sessions.
>
> I guess that's one choice. Couldn't you also stop the PMU and
> save/restore it's context in the notifiers? so that you wouldn't affect
> PM capabilities?
Yes, that's why I sent this an RFC. This solution can also be easily
ported to power domains, when we put them in place.
To save/restore PMU counters we can either reuse perf core (IIRC Dave
had a stab at this, it is not a trivial patch) or do arch specific
save/restore (with related buffers for registers context) but I think
Will does not like the idea at all (and he has a point since the context
memory is already there in perf core).
> That would imply that you lose the ability to profile after a certain
> point in suspend/idle, but maybe that's a better trade off than having
> profiling disable certain PM features?
I am ok either way, as long as we make a decision, it has been hanging
in the balance for aeons.
Thanks,
Lorenzo
next prev parent reply other threads:[~2015-03-12 10:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 17:31 [RFC PATCH 1/2] arm64: kernel: perf: add cpu hotplug notifier Lorenzo Pieralisi
2015-03-10 17:31 ` [RFC PATCH 2/2] arm64: kernel: perf: add pmu CPU PM notifier Lorenzo Pieralisi
2015-03-11 16:02 ` Kevin Hilman
2015-03-12 10:27 ` Lorenzo Pieralisi [this message]
2015-03-12 13:18 ` Ashwin Chaugule
2015-03-13 17:40 ` Lorenzo Pieralisi
2015-03-13 23:31 ` Kevin Hilman
2015-03-17 17:24 ` Will Deacon
2015-03-30 17:45 ` Lorenzo Pieralisi
2015-03-31 16:35 ` Kevin Hilman
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=20150312102733.GC18414@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).