All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan@bobich.net>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Virt overehead with HT [was: Re: Xen 4.5 development update]
Date: Tue, 15 Jul 2014 01:10:09 +0100	[thread overview]
Message-ID: <53C47161.1060008@bobich.net> (raw)
In-Reply-To: <1405377850.5333.17.camel@Solace>

On 07/14/2014 11:44 PM, Dario Faggioli wrote:
> On lun, 2014-07-14 at 19:31 +0100, Gordan Bobic wrote:
>> On 07/14/2014 06:22 PM, Dario Faggioli wrote:
>
>>> I'll try more runs, e.g. with number of VCPUs equal less than
>>> nr_corse/2 and see what happens.
>>>
>>> Again, thoughts?
>>
>> Have you tried it with VCPUs pinned to appropriate PCPUs?
>>
> Define "appropriate".
>
> I have a run for which I pinned VCPU#1-->PCPU#1, VCPU#2-->PCPU#2, and so
> on, and the result is even worse:
>
> Average Half load -j 4 Run (std deviation):
>   Elapsed Time 37.808 (0.538999)
> Average Optimal load -j 8 Run (std deviation):
>   Elapsed Time 26.594 (0.235223)
> Average Maximal load -j Run (std deviation):
>   Elapsed Time 27.9 (0.131149)
>
> This is actually something I expected, since you do not allow the VCPUs
> to move away from an HT with a busy sibling, even when it could have.
>
> In fact, you may expect better result from pinning only if you were to
> pin not only the VCPUs to the PCPUs, but also the kernbench's build jobs
> on the appropriate (V)CPUs in the guest.. but that's something not only
> really unpractical, but also very few representative as a benchmark, I
> think.
>
> If you pin VCPU#1 to PCPU#1 and VCPU#2 to PCPU#2, with PCPU#1 and PCPU#2
> being HT siblings, what prevents Linux (in the guest) to run two of the
> four build jobs on VCPU#1 and VCPU#2 (i.e., on siblings PCPUs!!) for all
> the length of the benchmark? Nothing, I think.

That would imply that Xen can somehow make a better decision that the 
domU's kernel scheduler, something that doesn't seem that likely. I 
would expect not pinning CPUs to increase process migration because Xen 
might migrate the CPU even though the kernel in domU decided which 
presented CPU was most lightly loaded.

> And in fact, pinning would also result in good (near to native,
> perhaps?) performance, if we were exposing the SMT topology details to
> guests as, in that case, Linux would do the balancing properly. However,
> that's not the case either. :-(

I see, so you are referring specifically to the HT case. I can see how 
that could cause a problem. Does pinning improve the performance with HT 
disabled?

Gordan

  reply	other threads:[~2014-07-15  0:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 16:43 Xen 4.5 development update konrad.wilk
2014-07-02 11:33 ` George Dunlap
2014-07-02 12:23   ` Jan Beulich
2014-07-11  6:51 ` Dario Faggioli
2014-07-14 16:12 ` Virt overehead with HT [was: Re: Xen 4.5 development update] Dario Faggioli
2014-07-14 16:32   ` Gordan Bobic
2014-07-14 16:44     ` Dario Faggioli
2014-07-14 16:55       ` George Dunlap
2014-07-14 17:22         ` Dario Faggioli
2014-07-14 18:31           ` Gordan Bobic
2014-07-14 22:44             ` Dario Faggioli
2014-07-15  0:10               ` Gordan Bobic [this message]
2014-07-15  2:30                 ` Dario Faggioli
2014-07-28 13:28                   ` Gordan Bobic

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=53C47161.1060008@bobich.net \
    --to=gordan@bobich.net \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=lars.kurth@citrix.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xenproject.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.