[PATCH 1/1] x86/cqm: Cqm requirements
From: Vikas Shivappa
Date: Tue Mar 07 2017 - 15:42:25 EST
Sending the cqm requirements as per Thomas comments in the previous
verson of cqm patch series -
https://marc.info/?l=linux-kernel&m=148374167726502
This is modified version of requirements sent by Tony in the same
thread with inputs from David and Stephan.
Reviewed-by: Tony Luck<tony.luck@xxxxxxxxx>
Reviewed-by: David Carrillo-Cisneros <davidcc@xxxxxxxxxx>
Reviewed-by: Yu Fenghua <fenghua.yu@xxxxxxxxx>
Reviewed-by: Stephane Eranian <eranian@xxxxxxxxxx>
Signed-off-by: Vikas Shivappa <vikas.shivappa@xxxxxxxxxxxxxxx>
General
1) Able to measure all RDT events (currently L3 occupancy,
Total B/W, Local B/W).
2) Report separate results per domain (currently L3 caches only).
3) Able to keep track of occupancy without requiring the creation of a
perf_event (avoid overhead of perf_events on ctxsw)
Thread Monitoring
4) Measure per thread, including kernel threads.
5) Put multiple threads into a single measurement group. No need for
cgroup-like hierarchy in measurement group.
6) Newly forked threads inherit parent's measurement group.
CAT/Allocation based monitoring
7) Able to monitor an existing resctrl CAT group (threads and cpus)
8) Can get measurements for subsets of tasks in a CAT group (to find the
threads hogging the resources).
Interface
9) Interface should be extensible to support changes of CLOSID in
measurement groups without affecting correctness of pre-existing measurement
groups. (See use case 5).
10) Interface should be extensible to work with perf's kernel API and be
compatible "as far as practical" with perf tool.
11) Interface should be extensible to support perf-like CPU filtering (i.e.
measure for all threads that run in a CPU, regardless of allocation group).
Use cases:
---------
1) use RDT to size jobs cache footprint to drive CAT partition sizing
2) Once CAT partition established, monitor actual resource usage of
jobs inside that partition, find resource hog or resize CAT partition
Change job's CAT partition without affecting monitoring. This is
useful when allocation requirements for a task group changes dynamically
and the number of distinct task groups is larger than the number of CLOSIDs.
3) Monitoring real time tasks. These may include tasks belonging to default
CAT group but run on a set of CPUs.
4) Monitor all allocations on a CPU.
5) When the number of desired allocation groups is less than number of available
CLOSIDs, jobs with different dynamic allocation needs may be combined into the
same allocation group. If dynamic allocation needs of one of the jobs change,
the job will change to a different allocation group. Monitoring of these jobs
should remain correct during allocation group moving.