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 v3 10/11] perf/x86/intel: Perform rotation on Intel CQM RMIDs
Date: Mon, 10 Nov 2014 20:56:53 +0000 [thread overview]
Message-ID: <20141110205653.GF1292@console-pimps.org> (raw)
In-Reply-To: <20141107122052.GD3337@twins.programming.kicks-ass.net>
On Fri, 07 Nov, at 01:20:52PM, Peter Zijlstra wrote:
> On Thu, Nov 06, 2014 at 12:23:21PM +0000, Matt Fleming wrote:
> > +/*
> > + * If we fail to assign a new RMID for intel_cqm_rotation_rmid because
> > + * cachelines are still tagged with RMIDs in limbo, we progressively
> > + * increment the threshold until we find an RMID in limbo with <=
> > + * __intel_cqm_threshold lines tagged. This is designed to mitigate the
> > + * problem where cachelines tagged with an RMID are not steadily being
> > + * evicted.
> > + *
> > + * On successful rotations we decrease the threshold back towards zero.
> > + *
> > + * __intel_cqm_max_threshold provides an upper bound on the threshold,
> > + * and is measured in bytes because it's exposed to userland.
> > + */
> > +static unsigned int __intel_cqm_threshold;
> > +static unsigned int __intel_cqm_max_threshold = -1;
>
> Should we initialize that to a finite value? Surely results are absolute
> crap if we do indeed reach that max?
I don't think we'll ever reach that max, it'll bottom out once it
reaches the size of the LLC, since the pathological case is that the
RMID you're currently trying to stabilize is used to tag every line in
the LLC.
Not sure what a reasonable finite value would be here though? 10% of the
LLC size?
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-11-10 20:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 12:23 [PATCH v3 00/11] perf: Intel Cache QoS Monitoring support Matt Fleming
2014-11-06 12:23 ` [PATCH 01/11] perf tools: Parse event per-package info files Matt Fleming
2014-11-06 12:23 ` [PATCH 02/11] perf tools: Implement snapshot event file logic Matt Fleming
2014-11-06 12:23 ` [PATCH 03/11] perf: Make perf_cgroup_from_task() global Matt Fleming
2014-11-06 12:23 ` [PATCH 04/11] perf: Add ->count() function to read per-package counters Matt Fleming
2014-11-06 12:23 ` [PATCH v3 05/11] perf: Move cgroup init before PMU ->event_init() Matt Fleming
2014-11-06 12:23 ` [PATCH 06/11] x86: Add support for Intel Cache QoS Monitoring (CQM) detection Matt Fleming
2014-11-06 12:23 ` [PATCH v3 07/11] perf/x86/intel: Add Intel Cache QoS Monitoring support Matt Fleming
2014-11-06 12:23 ` [PATCH 08/11] perf/x86/intel: Implement LRU monitoring ID allocation for CQM Matt Fleming
2014-11-06 12:23 ` [PATCH 09/11] perf/x86/intel: Support task events with Intel CQM Matt Fleming
2014-11-07 9:08 ` Peter Zijlstra
2014-11-07 10:09 ` Matt Fleming
2014-11-07 11:22 ` Peter Zijlstra
2014-11-06 12:23 ` [PATCH v3 10/11] perf/x86/intel: Perform rotation on Intel CQM RMIDs Matt Fleming
2014-11-07 12:06 ` Peter Zijlstra
2014-11-10 20:43 ` Matt Fleming
2014-11-10 20:58 ` Peter Zijlstra
2014-11-07 12:18 ` Peter Zijlstra
2014-11-10 20:50 ` Matt Fleming
2014-11-07 12:20 ` Peter Zijlstra
2014-11-10 20:56 ` Matt Fleming [this message]
2014-11-10 21:08 ` Peter Zijlstra
2014-11-07 12:34 ` Peter Zijlstra
2014-11-07 12:38 ` Peter Zijlstra
2014-11-14 12:35 ` Matt Fleming
2014-11-10 21:31 ` Matt Fleming
2014-11-11 9:37 ` Peter Zijlstra
2014-11-07 12:58 ` Peter Zijlstra
2014-11-06 12:23 ` [PATCH 11/11] perf/x86/intel: Enable conflicting event scheduling for CQM 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=20141110205653.GF1292@console-pimps.org \
--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).