linux-kernel - RE: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3908561D78D1C84285E8C5FCA982C28F3A2A8947@ORSMSX114.amr.corp.intel.com>
Date:   Wed, 1 Feb 2017 20:08:08 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        David Carrillo-Cisneros <davidcc@...gle.com>
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

> I was asking for requirements, not a design proposal. In order to make a
> design you need a requirements specification.

Here's what I came up with ... not a fully baked list, but should allow for some useful
discussion on whether any of these are not really needed, or if there is a glaring hole
that misses some use case:

1)	Able to measure using all supported events (currently L3 occupancy, Total B/W, Local B/W)
2)	Measure per thread
3)	Including kernel threads
4)	Put multiple threads into a single measurement group (forced by h/w shortage of RMIDs, but probably good to have anyway)
5)	New threads created inherit measurement group from parent
6)	Report separate results per domain (L3)
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)
10)	Put multiple CPUs into a group

Nice to have:
1)	Readout using "perf(1)" [subset of modes that make sense ... tying monitoring to resctrl file system will make most command line usage of perf(1) close to impossible.

-Tony