mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vikas Shivappa <vikas.shivappa@linux.intel.com>
To: vikas.shivappa@intel.com, tony.luck@intel.com
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com,
	tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org,
	ravi.v.shankar@intel.com, fenghua.yu@intel.com,
	andi.kleen@intel.com, davidcc@google.com, eranian@google.com,
	vikas.shivappa@linux.intel.com
Subject: [PATCH 1/1] x86/cqm: Cqm requirements
Date: Tue,  7 Mar 2017 09:49:24 -0800	[thread overview]
Message-ID: <1488908964-30261-1-git-send-email-vikas.shivappa@linux.intel.com> (raw)

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@intel.com>
Reviewed-by: David Carrillo-Cisneros <davidcc@google.com>
Reviewed-by: Yu Fenghua <fenghua.yu@intel.com>
Reviewed-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Vikas Shivappa <vikas.shivappa@linux.intel.com>

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.

             reply	other threads:[~2017-03-07 20:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 17:49 Vikas Shivappa [this message]
2017-03-07 19:31 ` Thomas Gleixner
2017-03-07 20:04   ` Luck, Tony
2017-03-07 20:22     ` Thomas Gleixner
2017-03-07 23:29     ` Stephane Eranian
2017-03-07 23:31       ` Shivappa Vikas
2017-03-08  8:30       ` Thomas Gleixner
2017-03-08 17:58         ` David Carrillo-Cisneros
2017-03-09 11:01           ` Thomas Gleixner
2017-03-09 18:05             ` David Carrillo-Cisneros
2017-03-10 14:53               ` Thomas Gleixner
2017-03-11  1:53                 ` David Carrillo-Cisneros
2017-03-13 19:10                   ` Thomas Gleixner
2017-03-13 19:58                     ` David Carrillo-Cisneros
2017-03-13 20:21                       ` Thomas Gleixner

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=1488908964-30261-1-git-send-email-vikas.shivappa@linux.intel.com \
    --to=vikas.shivappa@linux.intel.com \
    --cc=andi.kleen@intel.com \
    --cc=davidcc@google.com \
    --cc=eranian@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@intel.com \
    --cc=x86@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

all inboxes | Powered by JetHome®