From: Dario Faggioli <dario.faggioli@citrix.com>
To: "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
George Dunlap <George.Dunlap@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [RFC PATCH 3/7] xen: psr: reserve an RMID for each core
Date: Tue, 7 Apr 2015 10:07:18 +0000 [thread overview]
Message-ID: <1428401236.5671.16.camel@citrix.com> (raw)
In-Reply-To: <20150407082418.GC3404@pengc-linux.bj.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2163 bytes --]
On Tue, 2015-04-07 at 16:24 +0800, Chao Peng wrote:
> On Sat, Apr 04, 2015 at 04:14:41AM +0200, Dario Faggioli wrote:
> > 'persocket_cmt' would basically only allow to track the
> > amount of free L3 on each socket (by subtracting the
> > monitored value from the total). Again, still better
> > than nothing, would use very few RMIDs, and I could
> > think of ways of using this information in a few
> > places in the scheduler...
> >
> > Again, thought?
>
> This even can be extended to the concept of 'cache monitoring group',
> which can hold arbitrary cpus into one group.
>
Yes, indeed.
> Actually Linux
> implementation does this by using the cgoup mechanism to allocate RMID
> to a group of threads.
>
Does it? I dig the threads of the Linux's patches up to a certain point,
and it seemed that the maintainer disliked the idea of PSR-cgroups. I
have to admit I stopped at some point, and did not check how the
checked-in code actually looks like.
Anyway, yes, I'll explore the 'grouping idea'. In fact, in order to be
able to use CMT (and other PSR features) from inside the scheduler, the
shortage of RMIDs is probably not the biggest issue.
I'm much more concerned about the difficulties in making both "static"
monitoring (i.e., the per-core/per-group monitoring required by the
scheduler and other Xen components) and "dynamic" monitoring (i.e., the
per-domain monitoring, happening on user request, via `xl
psr-cmt-attach') play well together, if enabled at the same time.
If you've got time and are interested in providing your view on that, it
would be great.
> Such design can solve the RMID-shortage somehow.
>
Exactly. Actually, I've got a question: I think I remember reading on
Intel's SDM that RMID makes sense per-socket. If that is the case, it
means I can use, say, RMID #18 for both core 4, on socket 0, and core
73, on socket 2, do you confirm that? I'm asking because, as I said, I
think I read it in the manual, but the Xen implementation does not seem
to take advantage of this (perhaps because it wasn't necessary?).
Thanks and Regards,
Dario
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-04-07 10:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-04 2:14 [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities Dario Faggioli
2015-04-04 2:14 ` [RFC PATCH 1/7] x86: improve psr scheduling code Dario Faggioli
2015-04-06 13:48 ` Konrad Rzeszutek Wilk
2015-04-04 2:14 ` [RFC PATCH 2/7] Xen: x86: print max usable RMID during init Dario Faggioli
2015-04-06 13:48 ` Konrad Rzeszutek Wilk
2015-04-07 10:11 ` Dario Faggioli
2015-04-04 2:14 ` [RFC PATCH 3/7] xen: psr: reserve an RMID for each core Dario Faggioli
2015-04-06 13:59 ` Konrad Rzeszutek Wilk
2015-04-07 10:19 ` Dario Faggioli
2015-04-07 13:57 ` Konrad Rzeszutek Wilk
2015-04-07 8:24 ` Chao Peng
2015-04-07 10:07 ` Dario Faggioli [this message]
2015-04-08 13:28 ` George Dunlap
2015-04-08 14:03 ` Dario Faggioli
2015-04-04 2:14 ` [RFC PATCH 4/7] xen: libxc: libxl: report per-CPU cache occupancy up to libxl Dario Faggioli
2015-04-04 2:14 ` [RFC PATCH 5/7] xen: libxc: libxl: allow for attaching and detaching a CPU to CMT Dario Faggioli
2015-04-04 2:15 ` [RFC PATCH 6/7] xl: report per-CPU cache occupancy up to libxl Dario Faggioli
2015-04-04 2:15 ` [RFC PATCH 7/7] xl: allow for attaching and detaching a CPU to CMT Dario Faggioli
2015-04-07 8:19 ` [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities Chao Peng
2015-04-07 9:51 ` Dario Faggioli
2015-04-07 10:27 ` Andrew Cooper
2015-04-07 13:10 ` Dario Faggioli
2015-04-08 5:59 ` Chao Peng
2015-04-08 8:23 ` Dario Faggioli
2015-04-08 8:53 ` Andrew Cooper
2015-04-08 8:55 ` Chao Peng
2015-04-09 15:44 ` Meng Xu
2015-04-08 11:27 ` George Dunlap
2015-04-08 13:29 ` Dario Faggioli
2015-04-08 11:30 ` George Dunlap
2015-04-08 13:16 ` Dario Faggioli
2015-04-09 15:37 ` Meng Xu
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=1428401236.5671.16.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=George.Dunlap@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=chao.p.peng@linux.intel.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 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.