Michael S. Tsirkin writes: > On Thu, Jul 25, 2019 at 10:58:22AM -0400, Michael S. Tsirkin wrote: >> On Thu, Jul 25, 2019 at 04:42:42PM +0200, Sergio Lopez wrote: >> > >> > Paolo Bonzini 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. I just tried disabling everything that menuconfig allowed me to. Saves ~27KiB and doesn't improve boot time. > Trying with ACPI_REDUCED_HARDWARE_ONLY would also be educational. I also tried enabling this one in my original config. It saves ~11.5KiB, and has on impact on boot time either. >> >> > 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. >> > >> >>