From: Zhenyu Ye <yezhenyu2@huawei.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "S. Tsirkin, Michael" <mst@redhat.com>,
richard.henderson@linaro.org, qemu-devel@nongnu.org,
Xiexiangyou <xiexiangyou@huawei.com>,
yebiaoxiang <yebiaoxiang@huawei.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH v1] x86/cpu: initialize the CPU concurrently
Date: Mon, 21 Dec 2020 19:23:13 +0800 [thread overview]
Message-ID: <ea6a0aec-d63a-b67a-a4d4-ca09d5e3d6aa@huawei.com> (raw)
In-Reply-To: <20201218184754.GT3140057@habkost.net>
Hi Eduardo,
Thanks for your review.
On 2020/12/19 2:47, Eduardo Habkost wrote:
> On Wed, Nov 25, 2020 at 07:54:17PM +0800, Zhenyu Ye wrote:
>> From 0b4318c9dbf6fa152ec14eab29837ea06e2d78e5 Mon Sep 17 00:00:00 2001
>> From: eillon <yezhenyu2@huawei.com>
>> Date: Wed, 25 Nov 2020 19:17:03 +0800
>> Subject: [PATCH] x86/cpu: initialize the CPU concurrently
>>
>> Currently we initialize cpu one by one in qemu_init_vcpu(), every cpu
>> should have to wait util cpu->created = true. When cpus_accel->create_vcpu_thread
>> costs too long time or the number of CPUs is too large, this will prolong
>> the boot time.
>>
>
> How long was boot time before and after the patch?
>
When using haxm as the accelerator on windows, it takes at least
200ms to initialize one cpu. For a 4-core VM, it takes:
before 800ms -- 1000ms
after 200ms
Information about the processor on the host:
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
>
> I suggest doing this "wait for all CPUs" step outside qemu_init_vcpu().
>
> What about not making the last CPU special, and just providing a
> optional mechanism to wait for all VCPU threads after the CPU
> objects were created? e.g.:
>
Thanks for your suggestion and I will send PATCH v2 soon.
Thanks,
Zhenyu
prev parent reply other threads:[~2020-12-21 11:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 11:54 [RFC PATCH v1] x86/cpu: initialize the CPU concurrently Zhenyu Ye
2020-12-18 17:17 ` Igor Mammedov
2020-12-21 11:26 ` Zhenyu Ye
2020-12-18 18:47 ` Eduardo Habkost
2020-12-21 11:23 ` Zhenyu Ye [this message]
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=ea6a0aec-d63a-b67a-a4d4-ca09d5e3d6aa@huawei.com \
--to=yezhenyu2@huawei.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=xiexiangyou@huawei.com \
--cc=yebiaoxiang@huawei.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.