From: Matt Fleming <matt@console-pimps.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Kanaka Juvva <kanaka.d.juvva@intel.com>,
Matt Fleming <matt.fleming@intel.com>
Subject: Re: [PATCH v4 10/11] perf/x86/intel: Perform rotation on Intel CQM RMIDs
Date: Thu, 15 Jan 2015 19:37:23 +0000 [thread overview]
Message-ID: <20150115193723.GA12079@codeblueprint.co.uk> (raw)
In-Reply-To: <20150109155835.GJ29390@twins.programming.kicks-ass.net>
On Fri, 09 Jan, at 04:58:35PM, Peter Zijlstra wrote:
>
> Yeah, that'll work, when the free+limbo count is 1/4th the total we
> should stop pulling more plugs.
Perhaps something like this? It favours stealing more RMIDs over
increasing the "dirty threshold".
---
diff --git a/arch/x86/kernel/cpu/perf_event_intel_cqm.c b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
index fc1a90245601..af58f233c93c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_cqm.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
@@ -490,29 +490,27 @@ static unsigned int __rmid_queue_time_ms = RMID_DEFAULT_QUEUE_TIME;
/*
* intel_cqm_rmid_stabilize - move RMIDs from limbo to free list
- * @available: are there freeable RMIDs on the limbo list?
+ * @nr_available: number of freeable RMIDs on the limbo list
*
* Quiescent state; wait for all 'freed' RMIDs to become unused, i.e. no
* cachelines are tagged with those RMIDs. After this we can reuse them
* and know that the current set of active RMIDs is stable.
*
- * Return %true or %false depending on whether we were able to stabilize
- * an RMID for intel_cqm_rotation_rmid.
+ * Return %true or %false depending on whether stabilization needs to be
+ * reattempted.
*
- * If we return %false then @available is updated to indicate the reason
- * we couldn't stabilize any RMIDs. @available is %false if no suitable
- * RMIDs were found on the limbo list to recycle, i.e. no RMIDs had been
- * on the list for the minimum queue time. If @available is %true then,
- * we found suitable RMIDs to recycle but none had an associated
- * occupancy value below __intel_cqm_threshold and the threshold should
- * be increased and stabilization reattempted.
+ * If we return %true then @nr_available is updated to indicate the
+ * number of RMIDs on the limbo list that have been queued for the
+ * minimum queue time (RMID_AVAILABLE), but whose data occupancy values
+ * are above __intel_cqm_threshold.
*/
-static bool intel_cqm_rmid_stabilize(bool *available)
+static bool intel_cqm_rmid_stabilize(unsigned int *available)
{
struct cqm_rmid_entry *entry, *tmp;
lockdep_assert_held(&cache_mutex);
+ *available = 0;
list_for_each_entry(entry, &cqm_rmid_limbo_lru, list) {
unsigned long min_queue_time;
unsigned long now = jiffies;
@@ -539,7 +537,7 @@ static bool intel_cqm_rmid_stabilize(bool *available)
break;
entry->state = RMID_AVAILABLE;
- *available = true;
+ *available++;
}
/*
@@ -547,7 +545,7 @@ static bool intel_cqm_rmid_stabilize(bool *available)
* sitting on the queue for the minimum queue time.
*/
if (!*available)
- return false;
+ return true;
/*
* Test whether an RMID is free for each package.
@@ -684,9 +682,10 @@ static void intel_cqm_sched_out_events(struct perf_event *event)
static bool __intel_cqm_rmid_rotate(void)
{
struct perf_event *group, *start = NULL;
+ unsigned int threshold_limit;
unsigned int nr_needed = 0;
+ unsigned int nr_available;
bool rotated = false;
- bool available;
mutex_lock(&cache_mutex);
@@ -756,14 +755,41 @@ stabilize:
* Alternatively, if we didn't need to perform any rotation,
* we'll have a bunch of RMIDs in limbo that need stabilizing.
*/
- if (!intel_cqm_rmid_stabilize(&available)) {
- unsigned int limit;
+ threshold_limit = __intel_cqm_max_threshold / cqm_l3_scale;
+
+ while (intel_cqm_rmid_stabilize(&nr_available) &&
+ __intel_cqm_threshold < threshold_limit) {
+ unsigned int steal_limit;
+
+ /* Allow max 25% of RMIDs to be in limbo. */
+ steal_limit = (cqm_max_rmid + 1) / 4;
- limit = __intel_cqm_max_threshold / cqm_l3_scale;
- if (available && __intel_cqm_threshold < limit) {
- __intel_cqm_threshold++;
+ /*
+ * We failed to stabilize any RMIDs so our rotation
+ * logic is now stuck. In order to make forward progress
+ * we have a few options:
+ *
+ * 1. rotate ("steal") another RMID
+ * 2. increase the threshold
+ * 3. do nothing
+ *
+ * We do both of 1. and 2. until we hit the steal limit.
+ *
+ * The steal limit prevents all RMIDs ending up on the
+ * limbo list. This can happen if every RMID has a
+ * non-zero occupancy above threshold_limit, and the
+ * occupancy values aren't dropping fast enough.
+ *
+ * Note that there is prioritisation at work here - we'd
+ * rather increase the number of RMIDs on the limbo list
+ * than increase the threshold, because increasing the
+ * threshold skews the event data (because we reuse
+ * dirty RMIDs) - threshold bumps are a last resort.
+ */
+ if (nr_available < steal_limit)
goto again;
- }
+
+ __intel_cqm_threshold++;
}
out:
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-01-15 19:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 21:15 [PATCH v4 00/11] perf: Intel Cache QoS Monitoring support Matt Fleming
2014-11-14 21:15 ` [PATCH 01/11] perf tools: Parse event per-package info files Matt Fleming
2014-11-14 21:15 ` [PATCH 02/11] perf tools: Implement snapshot event file logic Matt Fleming
2014-11-14 21:15 ` [PATCH 03/11] perf: Make perf_cgroup_from_task() global Matt Fleming
2014-11-14 21:15 ` [PATCH 04/11] perf: Add ->count() function to read per-package counters Matt Fleming
2014-11-14 21:15 ` [PATCH 05/11] perf: Move cgroup init before PMU ->event_init() Matt Fleming
2014-11-14 21:15 ` [PATCH 06/11] x86: Add support for Intel Cache QoS Monitoring (CQM) detection Matt Fleming
2014-11-14 21:15 ` [PATCH 07/11] perf/x86/intel: Add Intel Cache QoS Monitoring support Matt Fleming
2014-11-14 21:15 ` [PATCH 08/11] perf/x86/intel: Implement LRU monitoring ID allocation for CQM Matt Fleming
2014-11-14 21:15 ` [PATCH v4 09/11] perf/x86/intel: Support task events with Intel CQM Matt Fleming
2014-11-14 21:15 ` [PATCH v4 10/11] perf/x86/intel: Perform rotation on Intel CQM RMIDs Matt Fleming
2015-01-06 16:13 ` Peter Zijlstra
2015-01-06 17:17 ` Peter Zijlstra
2015-01-09 12:14 ` Matt Fleming
2015-01-09 13:02 ` Peter Zijlstra
2015-01-09 15:24 ` Matt Fleming
2015-01-09 15:58 ` Peter Zijlstra
2015-01-15 15:31 ` Matt Fleming
2015-01-15 19:37 ` Matt Fleming [this message]
2015-01-06 17:36 ` Peter Zijlstra
2015-01-09 12:22 ` Matt Fleming
2015-01-09 12:59 ` Peter Zijlstra
2015-01-07 12:16 ` Peter Zijlstra
2015-01-09 12:55 ` Matt Fleming
2015-01-09 12:58 ` Peter Zijlstra
2015-01-11 10:45 ` Matt Fleming
2014-11-14 21:15 ` [PATCH 11/11] perf/x86/intel: Enable conflicting event scheduling for CQM Matt Fleming
2015-01-08 11:49 ` Peter Zijlstra
2015-01-09 12:56 ` Matt Fleming
2015-01-08 11:51 ` Peter Zijlstra
2015-01-09 14:27 ` Matt Fleming
2014-11-25 14:55 ` [PATCH v4 00/11] perf: Intel Cache QoS Monitoring support Matt Fleming
2014-12-18 7:59 ` Matt Fleming
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=20150115193723.GA12079@codeblueprint.co.uk \
--to=matt@console-pimps.org \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=kanaka.d.juvva@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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).