Thank you! 🙏

[urish]

I just wanted to say thanks for creating and maintaining this great project.

I use it to run GDB in the browser, and it's pretty amazing that this is even possible. I shared all the details, source code and praises to v86 in a blog post, as well as some of the alternatives that I tried. v86 has been a true enabler for this project.

Thank you so much!

[polygonnedpotato]

This does not deserve to be closed, like EVER!

[copy]

Thanks, I appreciate that!

A few suggestions to cut down the size more:

• If you haven't already, enable gzip compression for wasm files. They compress very well: The version of v86.wasm on my website is 288 kB gzipped, down from 1.9 mB
• v86 automatically decompresses zstd-compressed state images. Probably not applicable to you since you're creating the state image locally.
• State images can also be shrunk if you turn on CONFIG_PAGE_POISONING=y and CONFIG_PAGE_POISONING_ZERO=y in the kernel config, pass page_poison=on on the kernel command line and run echo 3 > /proc/sys/vm/drop_caches after boot. It causes the kernel to zero out unused memory pages, which are not included in the state image

[polygonnedpotato]

@copy: doesn't close the issue.
everyone:

[urish]

Thanks a lot for the optimization suggestions!

If you haven't already, enable gzip compression for wasm files. They compress very well: The version of v86.wasm on my website is 288 kB gzipped, down from 1.9 mB

the web server actually serves it gzipped, even though it's slightly bigger - 398504 bytes. libv86 also compresses pretty well, just 99887 bytes.

• State images can also be shrunk if you turn on CONFIG_PAGE_POISONING=y and CONFIG_PAGE_POISONING_ZERO=y in the kernel config, pass page_poison=on on the kernel command line and run echo 3 > /proc/sys/vm/drop_caches after boot. It causes the kernel to zero out unused memory pages, which are not included in the state image

What's the best way to detect that this command has finished running from the JavaScript end? I'm taking the snapshot automatically, so I need some way for the VM to tell the JS code when to take the snapshot.

Also, is there any way to speed up the boot process? looking at the output of dmesg, there seem to be a 3 second delay after the "PCI: CLS 0 bytes, default 32" message:

[    3.128385] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    3.135510] NET: Registered protocol family 1
[    3.136200] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    3.136680] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    3.137200] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    3.142995] pci 0000:00:12.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    3.143855] PCI: CLS 0 bytes, default 32
[    6.681885] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    6.685765] clocksource: Switched to clocksource tsc
[    6.685765] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    6.724184] Scanning for low memory corruption every 60 seconds
[    6.835870] Initialise system trusted keyrings

I wonder if this delay can be avoided by disabling something in the kernel configuration?

[copy]

What's the best way to detect that this command has finished running from the JavaScript end? I'm taking the snapshot automatically, so I need some way for the VM to tell the JS code when to take the snapshot.

I don't think you can. In my scripts I simply sleep 30 seconds.

I wonder if this delay can be avoided by disabling something in the kernel configuration?

I don't know. Let me know if you find out.

[cyberic99]

@urish there are some tips here that could be useful in your case, I think: https://bootlin.com/doc/training/boot-time/boot-time-slides.pdf. Booting the kernel with debug logs enabled could also help where the time is spent.

[urish]

Booting the kernel with debug logs enabled could also help where the time is spent.

Oh, wow!

Seems like sysfs/rootfs/tracefs (whatever that might be) are the main culprits. Not sure if there's anything I can do about it, but still fascinating to see this breakdown of the boot time:

[cyberic99]

nice!

I have found other optimizations here: https://fr.slideshare.net/righiandr/linux-boottime-23817352 and https://elinux.org/images/c/c1/Tools-and-techniques-for-reducing-bootup-time.pdf

maybe you could remove the loop devices, sysfs, tracefs, pnp support from the kernel?
and set CONFIG_SERIAL_8250_DETECT_IRQ to n

also, you can try playing with make tinyconfig