lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Feb 2017 17:39:31 +0000 From: "Luck, Tony" <tony.luck@...el.com> To: David Carrillo-Cisneros <davidcc@...gle.com>, Thomas Gleixner <tglx@...utronix.de> CC: Vikas Shivappa <vikas.shivappa@...ux.intel.com>, "Shivappa, Vikas" <vikas.shivappa@...el.com>, Stephane Eranian <eranian@...gle.com>, linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>, "Peter Zijlstra" <peterz@...radead.org>, "Shankar, Ravi V" <ravi.v.shankar@...el.com>, "Yu, Fenghua" <fenghua.yu@...el.com>, "Kleen, Andi" <andi.kleen@...el.com>, "Anvin, H Peter" <h.peter.anvin@...el.com> Subject: RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes >> 7) Must be able to measure based on existing resctrl CAT group >> 8) Can get measurements for subsets of tasks in a CAT group (to find the guys hogging the resources) >> 9) Measure per logical CPU (pick active RMID in same precedence for task/cpu as CAT picks CLOSID) > > I agree that "Measure per logical CPU" is a requirement, but why is > "pick active RMID in same precedence for task/cpu as CAT picks CLOSID" > one as well? Are we set on handling RMIDs the way CLOSIDs are > handled? there are drawbacks to do so, one is that it would make > impossible to do CPU monitoring and CPU filtering the way is done for > all other PMUs. I'm too focused on monitoring existing CAT groups. If we move the parenthetical remark from item 9, to item 7, then I think it is better. When monitoring a CAT group we need to monitor exactly the processes that are controlled by the CAT group. So RMID must match CLOSID, and the precedence rules make that work. For other monitoring cases we can do things differently - so long as we have a way to express what we want, and we don't pile a ton of code into context switch to figure out which RMID is to be loaded into PQR_ASSOC. I thought of another requirement this morning: N+1) When we set up monitoring we must allocate all the resources we need (or fail the setup if we can't get them). Not allowed to error in the middle of monitoring because we can't find a free RMID) -Tony
Powered by blists - more mailing lists