Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

On Thu, 2015-08-27 at 11:24 +0100, George Dunlap wrote:
> On 08/18/2015 04:55 PM, Dario Faggioli wrote:

> > *** Intel(R) Xeon(R) X5650 @ 2.67GHz
> > *** pCPUs      48        DOM0 vCPUS  16
> > *** RAM        393138 MB DOM0 Memory 9955 MB
> > *** NUMA nodes 2
> > =======================================================================================================================================
> > MAKE XEN (lower == better)
> > =======================================================================================================================================
> > # of build jobs                     -j1                   -j20                   -j24                  -j48**               -j62
> > vanilla/patched              vanilla    patched    vanilla    patched    vanilla    patched    vanilla    patched    vanilla    patched
> > ---------------------------------------------------------------------------------------------------------------------------------------
> >                               267.78     233.25      36.53      35.53      35.98      34.99      33.46      32.13      33.57      32.54
> >                               268.42     233.92      36.82      35.56      36.12       35.2      34.24      32.24      33.64      32.56
> >                               268.85     234.39      36.92      35.75      36.15      35.35      34.48      32.86      33.67      32.74
> >                               268.98     235.11      36.96      36.01      36.25      35.46      34.73      32.89      33.97      32.83
> >                               269.03     236.48      37.04      36.16      36.45      35.63      34.77      32.97      34.12      33.01
> >                               269.54     237.05      40.33      36.59      36.57      36.15      34.97      33.09      34.18      33.52
> >                               269.99     238.24      40.45      36.78      36.58      36.22      34.99      33.69      34.28      33.63
> >                               270.11     238.48      41.13      39.98      40.22      36.24         38      33.92      34.35      33.87
> >                               270.96     239.07      41.66      40.81      40.59      36.35      38.99      34.19      34.49      37.24
> >                               271.84     240.89      42.07      41.24      40.63      40.06      39.07      36.04      34.69      37.59
> > ---------------------------------------------------------------------------------------------------------------------------------------
> >  Avg.                         269.55    236.688     38.991     37.441     37.554     36.165      35.77     33.402     34.096     33.953
> > ---------------------------------------------------------------------------------------------------------------------------------------
> >  Std. Dev.                     1.213      2.503      2.312      2.288      2.031      1.452      2.079      1.142      0.379      1.882
> > ---------------------------------------------------------------------------------------------------------------------------------------
> >  % improvement                           12.191                 3.975                 3.699                 6.620                 0.419
> > ========================================================================================================================================
> 
> I'm a bit confused here as to why, if dom0 has 16 vcpus in all of your
> tests, you change the -j number (apparently) based on the number of
> pcpus available to Xen.  Wouldn't it make more sense to stick with
> 1/6/8/16/24?  That would allow us to have actually comparable numbers.
> 
Bah, no, sorry, that was a mistake I made when I cut-&-past'ed the
tables in the email... Dom0 always have as much vCPUs as the host has
pCPUs. I know this is a rather critical piece of information, so sorry
for messing it up! :-/

> But in any case, it seems to me that the numbers do show a uniform
> improvement and no regressions -- I think this approach looks really
> good, particularly as it is so small and well-contained.
> 
Yeah, that seems the case... But I really would like to try more
configurations and more workloads. I'll do that ASAP.

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]