From: Chao Peng <chao.p.peng@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org,
dgdegra@tycho.nsa.gov
Subject: Re: Cache Allocation Technology(CAT) design for XEN
Date: Wed, 17 Dec 2014 19:07:33 +0800 [thread overview]
Message-ID: <20141217110733.GC3105@pengc-linux.bj.intel.com> (raw)
In-Reply-To: <54900B91020000780004FCC2@mail.emea.novell.com>
On Tue, Dec 16, 2014 at 09:38:09AM +0000, Jan Beulich wrote:
> >>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> > Any comments from you? It would be greatly appreciated if you can look
> > at this when you have time. Your comments are always important to me :)
>
> I don't think I have to say much here:
>
> > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> >> Implementation Description
> >> ==========================
> >> In this design, one principal is that only implementing the cache
> >> enforcement mechanism in hypervisor but leaving the cache allocation
> >> policy to user space tool stack. In this way some complex governors then
> >> can be implemented in tool stack.
>
> With this, the changes to the hypervisor ought to be quite limited,
> even if length of the list you give seems long at a first glance, and
> hence I'm fine with the concept.
Thanks for your input.
>
> >> Hardware Limitation & Performance Improvement
> >> =============================================
> >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> >> switch. If the change is frequent then hardware may fail to strictly
> >> enforce the cache allocation basing on the specified COS.
>
> This certainly would deserve a little more explanation: What's the
> value of the functionality if one can't rely on it being enforced by
> hardware at all times?
OK. The hardware just can't enforce that strictly when cos is changed
frequently. But the performance is likely better overall because CAT limits
the amount of thrashing that the lower priority VM gets more cache.
If affinitized mode can be used, then strictly enforcement is guaranteed
by hardware. This is actually useful for scenarios like OpenStack NFV appliance
where vcpu are affinitized to specific logical threads.
Thanks,
Chao
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-12-17 11:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 12:27 Cache Allocation Technology(CAT) design for XEN Chao Peng
2014-12-12 15:02 ` Andrew Cooper
2014-12-15 8:47 ` Chao Peng
2014-12-16 8:55 ` Chao Peng
2014-12-16 9:38 ` Jan Beulich
2014-12-17 11:07 ` Chao Peng [this message]
2014-12-18 17:54 ` Auld, Will
2014-12-18 16:40 ` Tim Deegan
2014-12-19 6:09 ` Chao Peng
2014-12-19 9:43 ` Tim Deegan
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=20141217110733.GC3105@pengc-linux.bj.intel.com \
--to=chao.p.peng@linux.intel.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=will.auld@intel.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 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.