xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	He Chen <he.chen@linux.intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	ChaoPeng <chao.p.peng@linux.intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling
Date: Fri, 13 May 2016 18:17:53 +0200	[thread overview]
Message-ID: <1463156273.18789.38.camel@citrix.com> (raw)
In-Reply-To: <57359D05.30407@citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

On Fri, 2016-05-13 at 10:23 +0100, Andrew Cooper wrote:
> On 13/05/16 09:55, Jan Beulich wrote:
> > 
> > But anyway, L2 or L3 - I can't see how this context switching would
> > DTRT when there are vCPU-s of different domains on the same
> > socket (or core, if L2s and MSRs were per-core): The one getting
> > scheduled later onto a socket (core) would simply overwrite what
> > got written for the one which had been scheduled earlier.
> PSR_ASSOC is a per-thread MSR which selects the CLOS to use.  CLOS is
> currently managed per-domain in Xen, and context switched with vcpu.
> 
Yep, exactly. I did look a bit into this for CMT (so, not L3 CAT, but
it's not that different).

Doing things on a per-vcpu basis could be interesting, and that's even
more the case if we get to do L2 stuff, but there are two few RMIDs
available for such a configuration to be really useful.

> Xen programs different capacity bitmaps into IA32_L2_QOS_MASK_0 ...
> IA32_L2_QOS_MASK_n, and the CLOS selects which bitmap is enforced.
> 
So, basically, just to figure out if I understood (i.e., this is for He
Chen).

If we have a 2 sockets, with socket 0 containing cores 0,1,2,3 and
socket 1 containing cores 4,5,6,7, it will be possible to specify two
different "L2 reservation values" (in the form of CBMs, of course), for
a domain:
 - one would be how much L2 cache the domain will be able to use (say 
   X) when running on socket 1, which means on cores 0,1,2 or 3
 - another would be how much L2 cache the domain will be able to (say, 
   Y use when running on socket 2, which means on cores 4,5,6, or 7

Which in turn means, in case L2 is per core, the domain will get X of
core 0's L2, X of core 1's L2, X of core 2's L2 and X of core 3's L2.
On socket 1, it will get Y of core 4' L2, Y of core 5's L2 cache etc.
etc.

And so, in summary what we would not be able to specify is a different
value for the L2 reservations of, for instance, core 1 and core 3
(i.e., of cores that are part of the same socket).

Does this summary make sense?

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-05-13 16:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12  9:40 [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling He Chen
2016-05-12 10:05 ` Jan Beulich
2016-05-13  6:26   ` He Chen
2016-05-13  6:48     ` Jan Beulich
2016-05-13  7:43       ` Andrew Cooper
2016-05-13  8:55         ` Jan Beulich
2016-05-13  9:23           ` Andrew Cooper
2016-05-13 16:17             ` Dario Faggioli [this message]
2016-05-16  8:23               ` He Chen
2016-05-16  9:44                 ` Dario Faggioli
2016-05-12 10:06 ` Andrew Cooper
  -- strict thread matches above, loose matches on Subject: below --
2016-05-12  9:31 He Chen

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=1463156273.18789.38.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=he.chen@linux.intel.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).