From: Peter Zijlstra <peterz@infradead.org>
To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Cc: Tejun Heo <tj@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Li Zefan <lizefan@huawei.com>,
"containers@lists.linux-foundation.org"
<containers@lists.linux-foundation.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support
Date: Tue, 7 Jan 2014 09:34:40 +0100 [thread overview]
Message-ID: <20140107083440.GL30183@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1389048315.32504.57.camel@ppwaskie-mobl.amr.corp.intel.com>
On Mon, Jan 06, 2014 at 10:45:24PM +0000, Waskiewicz Jr, Peter P wrote:
> > Since its a very limited resource that seems like a weird assumption to
> > me; there's plenty scenarios in which you'd want to re-use RMIDs that
> > belong to a still running context.
>
> I think I see what you're really asking, let me rephrase to see if I'm
> now understanding you: What happens to a running process' cache
> assigned to one RMID when it's reassigned to a different RMID? Does the
> RMID get updated internally or does it appear as still belonging to the
> old RMID?
>
> If that's your question, then the CPU will update the cache entry with
> the correct RMID. It knows to do this because the when the process is
> scheduled, the OS will write the IA32_PQR_ASSOC MSR with the RMID map to
> start monitoring. That's when the RMID will be updated in the cache.
> However, any cacheline for a process that is moved to a different RMID,
> but doesn't have an opportunity to be scheduled, will still show up on
> the old RMID until it gets to run with the new RMID.
>
> Let me know if that better explains what I think you're asking.
Still confused here. So what you're saying is that cachelines get tagged
with {CR3,RMID} and when they observe the same CR3 with a different RMID
the hardware will iterate the entire cache and update all tuples?
That seems both very expensive and undesirable. It would mean you could
never use the RMID to creates slices of a process since you're stuck to
the CR3.
It also makes me wonder why we have the RMID at all; because if you're
already tagging every line with the CR3, why not build the cache monitor
on that. Just query the occupancy for all CR3s in your group and add.
The other possible interpretation is that it updates on-demand whenever
it touches a cacheline. But in that case, how do you deal with the
non-exclusive states? Does the last RMID to touch a non-exclusive
cacheline simply claim the entire line?
But that doesn't avoid the problem; because as soon as you change the
PQR_ASSOC RMID you still need to go run for a while to touch 'all' your
lines.
This duration is indeterminate; which again brings us back to needing to
first wipe the entire cache.
next prev parent reply other threads:[~2014-01-07 8:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 20:34 [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support Peter P Waskiewicz Jr
2014-01-03 20:34 ` [PATCH 1/4] x86: Add support for Cache QoS Monitoring (CQM) detection Peter P Waskiewicz Jr
2014-01-03 20:34 ` [PATCH 2/4] x86: Add Cache QoS Monitoring support to x86 perf uncore Peter P Waskiewicz Jr
2014-01-03 20:34 ` [PATCH 3/4] cgroup: Add new cacheqos cgroup subsys to support Cache QoS Monitoring Peter P Waskiewicz Jr
2014-01-03 20:34 ` [PATCH 4/4] Documentation: Add documentation for cacheqos cgroup Peter P Waskiewicz Jr
2014-01-04 16:10 ` [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support Tejun Heo
2014-01-04 22:43 ` Waskiewicz Jr, Peter P
2014-01-04 22:50 ` Tejun Heo
2014-01-05 5:23 ` Waskiewicz Jr, Peter P
2014-01-06 11:16 ` Peter Zijlstra
2014-01-06 16:34 ` Waskiewicz Jr, Peter P
2014-01-06 16:41 ` Peter Zijlstra
2014-01-06 16:47 ` Waskiewicz Jr, Peter P
2014-01-06 17:53 ` Peter Zijlstra
2014-01-06 18:05 ` Waskiewicz Jr, Peter P
2014-01-06 18:06 ` Peter Zijlstra
2014-01-06 20:10 ` Waskiewicz Jr, Peter P
2014-01-06 21:26 ` Peter Zijlstra
2014-01-06 21:48 ` Waskiewicz Jr, Peter P
2014-01-06 22:12 ` Peter Zijlstra
2014-01-06 22:45 ` Waskiewicz Jr, Peter P
2014-01-07 8:34 ` Peter Zijlstra [this message]
2014-01-07 15:15 ` Waskiewicz Jr, Peter P
2014-01-07 21:12 ` Peter Zijlstra
2014-01-10 18:55 ` Waskiewicz Jr, Peter P
2014-01-13 7:55 ` Peter Zijlstra
2014-01-14 17:58 ` H. Peter Anvin
2014-01-27 17:34 ` Peter Zijlstra
2014-02-18 17:29 ` Waskiewicz Jr, Peter P
2014-02-18 19:35 ` Peter Zijlstra
2014-02-18 19:54 ` Waskiewicz Jr, Peter P
2014-02-20 16:58 ` Peter Zijlstra
2014-01-14 20:46 ` Waskiewicz Jr, Peter P
2014-01-06 11:08 ` Peter Zijlstra
2014-01-06 16:42 ` Waskiewicz Jr, Peter P
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=20140107083440.GL30183@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mingo@redhat.com \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.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