From: Laurent Vivier <lvivier@redhat.com>
To: Paul Mackerras <paulus@samba.org>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org,
Alexander Graf <agraf@suse.de>,
david@gibson.dropbear.id.au
Subject: Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
Date: Mon, 22 Jun 2015 10:37:07 +0000 [thread overview]
Message-ID: <5587E553.6080101@redhat.com> (raw)
In-Reply-To: <20150622000902.GC12053@iris.ozlabs.ibm.com>
On 22/06/2015 02:09, Paul Mackerras wrote:
> On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote:
>>
>> Tested-by: Laurent Vivier <lvivier@redhat.com>
>>
>> Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ?
>> Did I miss something ?
>>
>> My test system is an IBM Power S822L.
>>
>> I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both
>> attached on the same core (with pinning option of virt-manager). Then, I
>> measure the time needed to compile a kernel in parallel in both guests
>> with "make -j 16".
>>
>> My kernel without micro-threading:
>>
>> real 37m23.424s real 37m24.959s
>> user 167m31.474s user 165m44.142s
>> sys 113m26.195s sys 113m45.072s
>>
>> With micro-threading patches (PATCH 1+2):
>>
>> target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is > max threads/sub-core]
>> dynamic_mt_modes 6
>>
>> real 32m13.338s real 32m26.652s
>> user 139m21.181s user 140m20.994s
>> sys 77m35.339s sys 78m16.599s
>>
>> It's better, but if I disable dynamic micro-threading (but PATCH 1+2):
>>
>> target_smt_mode 0
>> dynamic_mt_modes 0
>>
>> real 30m49.100s real 30m48.161s
>> user 144m22.989s user 142m53.886s
>> sys 65m4.942s sys 66m8.159s
>>
>> it's even better.
>
> I think what's happening here is that with dynamic_mt_modes=0 the
> system alternates between the two guests, whereas with
> dynamic_mt_modes=6 it will spend some of the time running both guests
> simultaneously in two-way split mode. Since you have two
> compute-bound guests that each have threads=1 and 8 vcpus, it can fill
> up the core either way. In that case it is more efficient to fill up
> the core with vcpus from one guest and not have to split the core,
> firstly because you avoid the split/unsplit latency and secondly
> because the threads run a little faster in whole-core mode than in
> split-core.
Thank you for the explanation.
So it has more sense to have vCPUs with threads ?
It seems:
I did same tests with 4 vCPUs x 2 threads x 2 guests concurrently on one
8 threaded bare metal core.
target_smt_mode 0
dynamic_mt_modes 0
real 35m33.142s real 35m44.967s
user 167m16.971s user 163m14.320s
sys 84m19.618s sys 90m38.978s
target_smt_mode 0
dynamic_mt_modes 6
real 26m41.993s real 25m54.270s
user 130m31.362s user 127m55.145s
sys 58m17.378s sys 55m10.202s
In this case, it really improves performance.
Laurent
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Vivier <lvivier@redhat.com>
To: Paul Mackerras <paulus@samba.org>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org,
Alexander Graf <agraf@suse.de>,
david@gibson.dropbear.id.au
Subject: Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
Date: Mon, 22 Jun 2015 12:37:07 +0200 [thread overview]
Message-ID: <5587E553.6080101@redhat.com> (raw)
In-Reply-To: <20150622000902.GC12053@iris.ozlabs.ibm.com>
On 22/06/2015 02:09, Paul Mackerras wrote:
> On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote:
>>
>> Tested-by: Laurent Vivier <lvivier@redhat.com>
>>
>> Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ?
>> Did I miss something ?
>>
>> My test system is an IBM Power S822L.
>>
>> I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both
>> attached on the same core (with pinning option of virt-manager). Then, I
>> measure the time needed to compile a kernel in parallel in both guests
>> with "make -j 16".
>>
>> My kernel without micro-threading:
>>
>> real 37m23.424s real 37m24.959s
>> user 167m31.474s user 165m44.142s
>> sys 113m26.195s sys 113m45.072s
>>
>> With micro-threading patches (PATCH 1+2):
>>
>> target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is > max threads/sub-core]
>> dynamic_mt_modes 6
>>
>> real 32m13.338s real 32m26.652s
>> user 139m21.181s user 140m20.994s
>> sys 77m35.339s sys 78m16.599s
>>
>> It's better, but if I disable dynamic micro-threading (but PATCH 1+2):
>>
>> target_smt_mode 0
>> dynamic_mt_modes 0
>>
>> real 30m49.100s real 30m48.161s
>> user 144m22.989s user 142m53.886s
>> sys 65m4.942s sys 66m8.159s
>>
>> it's even better.
>
> I think what's happening here is that with dynamic_mt_modes=0 the
> system alternates between the two guests, whereas with
> dynamic_mt_modes=6 it will spend some of the time running both guests
> simultaneously in two-way split mode. Since you have two
> compute-bound guests that each have threads=1 and 8 vcpus, it can fill
> up the core either way. In that case it is more efficient to fill up
> the core with vcpus from one guest and not have to split the core,
> firstly because you avoid the split/unsplit latency and secondly
> because the threads run a little faster in whole-core mode than in
> split-core.
Thank you for the explanation.
So it has more sense to have vCPUs with threads ?
It seems:
I did same tests with 4 vCPUs x 2 threads x 2 guests concurrently on one
8 threaded bare metal core.
target_smt_mode 0
dynamic_mt_modes 0
real 35m33.142s real 35m44.967s
user 167m16.971s user 163m14.320s
sys 84m19.618s sys 90m38.978s
target_smt_mode 0
dynamic_mt_modes 6
real 26m41.993s real 25m54.270s
user 130m31.362s user 127m55.145s
sys 58m17.378s sys 55m10.202s
In this case, it really improves performance.
Laurent
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
next prev parent reply other threads:[~2015-06-22 10:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 5:17 [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core Paul Mackerras
2015-05-28 5:17 ` Paul Mackerras
2015-05-28 5:17 ` [PATCH 1/2] KVM: PPC: Book3S HV: Make use of unused threads when running guests Paul Mackerras
2015-05-28 5:17 ` Paul Mackerras
2015-06-02 6:29 ` David Gibson
2015-06-02 6:29 ` David Gibson
2015-05-28 5:17 ` [PATCH 2/2] KVM: PPC: Book3S HV: Implement dynamic micro-threading on POWER8 Paul Mackerras
2015-05-28 5:17 ` Paul Mackerras
2015-06-03 1:29 ` David Gibson
2015-06-03 1:29 ` David Gibson
2015-06-24 10:33 ` [PATCH v2] " Paul Mackerras
2015-06-24 10:33 ` Paul Mackerras
2015-06-17 17:30 ` [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core Laurent Vivier
2015-06-17 17:30 ` Laurent Vivier
2015-06-22 0:09 ` Paul Mackerras
2015-06-22 0:09 ` Paul Mackerras
2015-06-22 10:37 ` Laurent Vivier [this message]
2015-06-22 10:37 ` Laurent Vivier
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=5587E553.6080101@redhat.com \
--to=lvivier@redhat.com \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=paulus@samba.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.