From: Dario Faggioli <dario.faggioli@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
Volodymyr Babchuk <vlad.babchuk@gmail.com>
Cc: Artem_Mygaiev@epam.com, Julien Grall <julien.grall@arm.com>,
xen-devel@lists.xensource.com,
Andrii Anisov <andrii_anisov@epam.com>,
George Dunlap <george.dunlap@citrix.com>
Subject: Re: Notes on stubdoms and latency on ARM
Date: Wed, 12 Jul 2017 08:14:51 +0200 [thread overview]
Message-ID: <1499840091.7756.12.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1707071407590.2919@sstabellini-ThinkPad-X260>
[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]
On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
> > > >
> > > Since you are using Credit, can you try to disable context switch
> > > rate
> > > limiting?
> >
> > Yep. You are right. In the environment described above (Case 2) I
> > now
> > get much better results:
> >
> > real 1.85
> > user 0.00
> > sys 1.85
>
> From 113 to 1.85 -- WOW!
>
> Obviously I am no scheduler expert, but shouldn't we advertise a bit
> better a scheduler configuration option that makes things _one
> hundred
> times faster_ ?!
>
So, to be fair, so far, we've bitten this hard by this only on
artificially constructed test cases, where either some extreme
assumption were made (e.g., that all the vCPUs except one always run at
100% load) or pinning was used in a weird and suboptimal way. And there
are workload where it has been verified that it helps making
performance better (poor SpecVIRT results without it was the main
motivation having it upstream, and on by default).
That being said, I personally have never liked rate-limiting, it always
looked to me like the wrong solution.
> It's not even mentioned in
> https://wiki.xen.org/wiki/Tuning_Xen_for_Performance!
>
Well, for sure it should be mentioned here, you're right!
> Also, it is worrying to me that there are cases were, unless the user
> tweaks the configuration, she is going to get 100x worse performance
> out
> of her system.
>
As I said, it's hard to tell in advance whether it will have a good,
bad, or really bad impact on a specific workload.
I'm starting to think, though, that it may be good to switch to having
it off by default, and then document that if the system is going into
trashing because of too frequent context switches, turning it on may
help.
I'll think about it, and see if I'll be able to run some benchmarks
with it on and off.
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: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-07-12 6:14 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 19:00 Notes on stubdoms and latency on ARM Stefano Stabellini
2017-05-19 19:45 ` Volodymyr Babchuk
2017-05-22 21:41 ` Stefano Stabellini
2017-05-26 19:28 ` Volodymyr Babchuk
2017-05-30 17:29 ` Stefano Stabellini
2017-05-30 17:33 ` Julien Grall
2017-06-01 10:28 ` Julien Grall
2017-06-17 0:17 ` Volodymyr Babchuk
2017-05-31 9:09 ` George Dunlap
2017-05-31 15:53 ` Dario Faggioli
2017-05-31 16:17 ` Volodymyr Babchuk
2017-05-31 17:45 ` Stefano Stabellini
2017-06-01 10:48 ` Julien Grall
2017-06-01 10:52 ` George Dunlap
2017-06-01 10:54 ` George Dunlap
2017-06-01 12:40 ` Dario Faggioli
2017-06-01 15:02 ` George Dunlap
2017-06-01 18:27 ` Stefano Stabellini
2017-05-31 17:02 ` George Dunlap
2017-06-17 0:14 ` Volodymyr Babchuk
2017-06-19 9:37 ` George Dunlap
2017-06-19 17:54 ` Stefano Stabellini
2017-06-19 18:36 ` Volodymyr Babchuk
2017-06-20 10:11 ` Dario Faggioli
2017-07-07 15:02 ` Volodymyr Babchuk
2017-07-07 16:41 ` Dario Faggioli
2017-07-07 17:03 ` Volodymyr Babchuk
2017-07-07 21:12 ` Stefano Stabellini
2017-07-12 6:14 ` Dario Faggioli [this message]
2017-07-17 9:25 ` George Dunlap
2017-07-17 10:04 ` Julien Grall
2017-07-17 11:28 ` George Dunlap
2017-07-19 11:21 ` Julien Grall
2017-07-20 9:25 ` Dario Faggioli
2017-07-20 9:10 ` Dario Faggioli
2017-07-20 8:49 ` Dario Faggioli
2017-07-08 14:26 ` Dario Faggioli
2017-06-20 10:45 ` Julien Grall
2017-06-20 16:23 ` Volodymyr Babchuk
2017-06-21 10:38 ` Julien Grall
2017-06-19 18:26 ` Volodymyr Babchuk
2017-06-20 10:00 ` Dario Faggioli
2017-06-20 10:30 ` George Dunlap
2017-05-23 7:11 ` Dario Faggioli
2017-05-26 20:09 ` Volodymyr Babchuk
2017-05-27 2:10 ` Dario Faggioli
2017-05-23 9:08 ` George Dunlap
2017-05-26 19:43 ` Volodymyr Babchuk
2017-05-26 19:46 ` Volodymyr Babchuk
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=1499840091.7756.12.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=Artem_Mygaiev@epam.com \
--cc=andrii_anisov@epam.com \
--cc=george.dunlap@citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xensource.com \
/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.