Messages in this thread | | | Date | Mon, 6 Jan 2014 19:06:36 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support |
| |
On Mon, Jan 06, 2014 at 04:47:57PM +0000, Waskiewicz Jr, Peter P wrote: > > As is I don't really see a good use for RMIDs and I would simply not use > > them. > > If you want to use CQM in the hardware, then the RMID is how you get the > cache usage data from the CPU. If you don't want to use CQM, then you > can ignore RMIDs.
I think you can make do with a single RMID (per cpu). When you program the counter (be it for a task, cpu or cgroup context) you set the 1 RMID and EVSEL and read the CTR.
What I'm not entirely clear on is if the EVSEL and CTR MSR are per logical CPU or per L3 (package); /me prays they're per logical CPU.
> One of the best use cases for using RMIDs is in virtualization.
*groan*.. /me plugs wax in ears and goes la-la-la-la
> A VM > may be a heavy cache user, or a light cache user. Tracing different VMs > on different RMIDs can allow an admin to identify which VM may be > causing high levels of eviction, and either migrate it to another host, > or move other tasks/VMs to other hosts. Without CQM, it's much harder > to find which process is eating the cache up.
Not necessarily VMs, there's plenty large processes that exhibit similar problems.. why must people always do VMs :-(
That said, even with a single RMID you can get that information by simply running it against all competing processes one at a time. Since there's limited RMID space you need to rotate at some point anyway.
The cgroup interface you propose wouldn't allow for rotation; other than manual by creating different cgroups one after another.
| |