All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vikas Shivappa <vikas.shivappa@linux.intel.com>
To: vikas.shivappa@intel.com
Cc: vikas.shivappa@linux.intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com, tglx@linutronix.de,
	mingo@kernel.org, tj@kernel.org, peterz@infradead.org,
	matt.fleming@intel.com, will.auld@intel.com,
	h.peter.anvin@intel.com, glenn.p.williamson@intel.com,
	kanaka.d.juvva@intel.com, bruce.schlobohm@intel.com
Subject: [PATCH V14 0/9] Intel cache allocation and Hot cpu handling changes to cqm, rapl
Date: Wed,  9 Sep 2015 12:24:51 -0700	[thread overview]
Message-ID: <1441826702-6975-1-git-send-email-vikas.shivappa@linux.intel.com> (raw)

There was a push back from cgroup maintainer Tejun on cgroup interface
usage during the previous version of patches. This patch series splits
the prior V13 patches to separate the cqos framework parts which just
provide APis to manage the closid/cbm management, scheduling, hot cpu etc
and the cgroup interface parts into separate patches. Basically splits
into parts which dont have any major push back and are mostly reviewed
and the ones which have push back.

1/11 - 9/11 contain patches which has only the x86 cqos parts which 
have received a lot of feedback from
tglx and Peter and other x86 specific feedbacks. 
All the feedbacks are addressed in these patches.
These patches include some preparatory patches to improve the hot cpu
handling code in cqm and rapl like earlier versions.

10/11 - 11/11 has the cgroup interface patches.

*All patches will apply on 4.2*

Changes in V14:
 - separate patches for cache alloc kernel framework and cgroup
 interface
 - introduces a field closid in task_struct to keep track of the closid
 for the task in the framework patches (1/11 - 9/11). The closid field
 is removed by the cgroup interface patch as we already have a cgroups
 field in the task_struct which the cgroup interface just uses.
 - The documentation is also split into two - one for the cache alloc
 kernel implementation itself and one for cgroup interface.

[PATCH 01/11] x86/intel_cqm: Modify hot cpu notification handling
[PATCH 02/11] x86/intel_rapl: Modify hot cpu notification handling
[PATCH 03/11] x86/intel_rdt: Cache Allocation documentation
[PATCH 04/11] x86/intel_rdt: Add support for Cache Allocation
[PATCH 05/11] x86/intel_rdt: Add Class of service management
[PATCH 06/11] x86/intel_rdt: Add L3 cache capacity bitmask management
[PATCH 07/11] x86/intel_rdt: Implement scheduling support for Intel
[PATCH 08/11] x86/intel_rdt: Hot cpu support for Cache Allocation
[PATCH 09/11] x86/intel_rdt: Intel haswell Cache Allocation
[PATCH 10/11] x86,cgroup/intel_rdt : Add intel_rdt cgroup
[PATCH 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Cache allocation

             reply	other threads:[~2015-09-09 19:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 19:24 Vikas Shivappa [this message]
2015-09-09 19:24 ` [PATCH 01/11] x86/intel_cqm: Modify hot cpu notification handling Vikas Shivappa
2015-09-09 19:24 ` [PATCH 02/11] x86/intel_rapl: " Vikas Shivappa
2015-09-09 19:24 ` [PATCH 03/11] x86/intel_rdt: Cache Allocation documentation Vikas Shivappa
2015-09-09 19:24 ` [PATCH 04/11] x86/intel_rdt: Add support for Cache Allocation detection Vikas Shivappa
2015-09-09 19:24 ` [PATCH 05/11] x86/intel_rdt: Add Class of service management Vikas Shivappa
2015-09-09 19:24 ` [PATCH 06/11] x86/intel_rdt: Add L3 cache capacity bitmask management Vikas Shivappa
2015-09-09 19:24 ` [PATCH 07/11] x86/intel_rdt: Implement scheduling support for Intel RDT Vikas Shivappa
2015-09-09 19:24 ` [PATCH 08/11] x86/intel_rdt: Hot cpu support for Cache Allocation Vikas Shivappa
2015-09-09 19:25 ` [PATCH 09/11] x86/intel_rdt: Intel haswell Cache Allocation enumeration Vikas Shivappa
2015-09-09 19:25 ` [PATCH 10/11] x86,cgroup/intel_rdt : Add intel_rdt cgroup documentation Vikas Shivappa
2015-09-09 19:25 ` [PATCH 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation Vikas Shivappa

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=1441826702-6975-1-git-send-email-vikas.shivappa@linux.intel.com \
    --to=vikas.shivappa@linux.intel.com \
    --cc=bruce.schlobohm@intel.com \
    --cc=glenn.p.williamson@intel.com \
    --cc=h.peter.anvin@intel.com \
    --cc=hpa@zytor.com \
    --cc=kanaka.d.juvva@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vikas.shivappa@intel.com \
    --cc=will.auld@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.