[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type |
Date: |
Thu, 25 Jul 2019 10:58:22 -0400 |
On Thu, Jul 25, 2019 at 04:42:42PM +0200, Sergio Lopez wrote:
>
> Paolo Bonzini <address@hidden> writes:
>
> > On 25/07/19 15:26, Stefan Hajnoczi wrote:
> >> The microvm design has a premise and it can be answered definitively
> >> through performance analysis.
> >>
> >> If I had to explain to someone why PCI or ACPI significantly slows
> >> things down, I couldn't honestly do so. I say significantly because
> >> PCI init definitely requires more vmexits but can it be a small
> >> number? For ACPI I have no idea why it would consume significant
> >> amounts of time.
> >
> > My guess is that it's just a lot of code that has to run. :(
>
> I think I haven't shared any numbers about ACPI.
>
> I don't have details about where exactly the time is spent, but
> compiling a guest kernel without ACPI decreases the average boot time in
> ~12ms, and the kernel's unstripped ELF binary size goes down in a
> whooping ~300KiB.
At least the binary size is hardly surprising.
I'm guessing you built in lots of drivers.
It would be educational to try to enable ACPI core but disable all
optional features.
> On the other hand, removing ACPI from QEMU decreases its initialization
> time in ~5ms, and the binary size is ~183KiB smaller.
Yes - ACPI generation uses a ton of allocations and data copies.
Need to play with pre-allocation strategies. Maybe something
as simple as:
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index f3fdfefcd5..24becc069e 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2629,8 +2629,10 @@ void acpi_build(AcpiBuildTables *tables, MachineState
*machine)
acpi_get_pci_holes(&pci_hole, &pci_hole64);
acpi_get_slic_oem(&slic_oem);
+#define DEFAULT_ARRAY_SIZE 16
table_offsets = g_array_new(false, true /* clear */,
- sizeof(uint32_t));
+ sizeof(uint32_t),
+ DEFAULT_ARRAY_SIZE);
ACPI_BUILD_DPRINTF("init ACPI tables\n");
bios_linker_loader_alloc(tables->linker,
will already help a bit.
>
> IMHO, those are pretty relevant savings on both fronts.
>
> >> Until we have this knowledge, the premise of microvm is unproven and
> >> merging it would be premature because maybe we can get into the same
> >> ballpark by optimizing existing code.
> >>
> >> I'm sorry for being a pain. I actually think the analysis will
> >> support microvm, but it still needs to be done in order to justify it.
> >
> > No, you're not a pain, you're explaining your reasoning and that helps.
> >
> > To me *maintainability is the biggest consideration* when introducing a
> > new feature. "We can do just as well with q35" is a good reason to
> > deprecate and delete microvm, but not a good reason to reject it now as
> > long as microvm is good enough in terms of maintainability. Keeping it
> > out of tree only makes it harder to do this kind of experiment. virtio
> > 1 seems to be the biggest remaining blocker and I think it'd be a good
> > thing to have even for the ARM virt machine type.
> >
> > FWIW the "PCI tax" seems to be ~10 ms in QEMU, ~10 ms in the firmware(*)
> > and ~25 ms in the kernel. I must say that's pretty good, but it's still
> > 30% of the whole boot time and reducing it is the hardest part. If
> > having microvm in tree can help reducing it, good. Yes, it will get
> > users, but most likely they will have to support pc or q35 as a fallback
> > so we could still delete microvm at any time with the due deprecation
> > period if it turns out to be a failed experiment.
> >
> > Whether to use qboot or SeaBIOS for microvm is another story, but it's
> > an implementation detail as long as the ROM size doesn't change and/or
> > we don't do versioned machine types. So we can switch from one to the
> > other at any time; we can also include qboot directly in QEMU's tree,
> > without going through a submodule, which also reduces the infrastructure
> > needed (mirrors, etc.) and makes it easier to delete it.
> >
> > Paolo
> >
> > (*) I measured 15ms in SeaBIOS and 5ms in qboot from the first to the
> > last write to 0xcf8. I suspect part of qboot's 10ms boot time actually
> > end up measured as PCI in SeaBIOS, due to different init order, so the
> > real firmware cost of PAM and PCI initialization should be 5ms for qboot
> > and 10ms for SeaBIOS.
>
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, (continued)
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Stefan Hajnoczi, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Paolo Bonzini, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Paolo Bonzini, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Peter Maydell, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Paolo Bonzini, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Sergio Lopez, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Paolo Bonzini, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Igor Mammedov, 2019/07/26
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Sergio Lopez, 2019/07/25
- Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Michael S. Tsirkin, 2019/07/25
Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, no-reply, 2019/07/02
Re: [Qemu-devel] [PATCH v3 0/4] Introduce the microvm machine type, Stefan Hajnoczi, 2019/07/03