Re: [PATCH 00/19] Assorted fixes and improvements to Credit2

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

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

On Mon, 2016-06-20 at 01:43 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 17.06.16 at 19:32, <dario.faggioli@citrix.com> wrote:
> > > -------------------------------------|---------------------------------|
> > > Xen build, high VM load, with noise | Iperf, high VM load, with noise |
> > > -------------------------------------|---------------------------------|
> > >            runq=core   runq=socket  |           runq=core runq=socket |
> > > baseline     41.466       30.630    | baseline    20.333     20.633   |
> > > patched      36.840       29.080    | patched     19.967     21.000   |
> > > =======================================================================|
> > Which, summarizing, means:
> >  * as far as Credit2 is concerned,  applying this series and using
> > runq=socket
> >    is what _ALWAYS_ provides the best results.
> Always? What about the increase on far the right side of the above
> table fragment? It's not a big change, but anyway.
> 
Not sure I follow. By 'far the right side' you mean the results of
"Iperf, high VM load, with noise"?

If yes, the 'patched' and 'runq=socket' element shows the highest
value, which in this case is a good thing, because this is Iperf and
the number is the total throughput in Gbps, and the higher it is, the
better.

> > [*] Jan, I confirm that, with your series applied, I haven't yet
> > seen any of
> > those "Time went backwards?" printk from Credit2, as you sort of
> > were
> > expecting...
> Well, that's better than I had expected then: I didn't really think
> they would be gone entirely. How long of an uptime did your tests
> cover? As noted in the cover letter, I've observed remaining odd
> TSC/stime jumps to increase in range over time, with no explanation
> so far.
> 
The total uptime of one run of this benchmarks is a handful of minutes,
so that's probably why I don't see any problem.

> Also I wonder whether I may translate your statement above to
> a Tested-by for part or all of the series (right now there's only a
> coding style fix to one of the patches and a slight extension to
> the rdtsc_ordered() one pending for an eventual v2).
> 
Indeed you can... I was in fact planning to reply directly to the
series' thread with that.

I've applied, and hence tested, the full series.

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