[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v1] x86/cpu: initialize the CPU concurrently
From: |
Zhenyu Ye |
Subject: |
Re: [RFC PATCH v1] x86/cpu: initialize the CPU concurrently |
Date: |
Mon, 21 Dec 2020 19:23:13 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 |
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