Open hrw opened 4 years ago
I think that once we find out values by hand then set of CI tests needs to be added.
is thet memroy needed including the qemu overhead or is that just the ram allocated to the instnace.
i was not expecting to see the guest ram requiremetns change with a change in bootloader if it include the emulator overhead then i would have expeced q35 to reuire more then i440fx due to some of the devices associated with each machine type notabley the fact that q35 used pcie vs a pci bus on i440fx
in the openstack ci we had been useing 64mb for ram for the older cirros images but we do have space to increase that. im just surpised to see uefi having an effect.
any idea why? is this due to uefi runtime service consuming ram or is this deivce memory? e.g. memory reserved for pcie device mmio regions ?
For CirrOS 0.6 instance memory requirements look like that:
Notes:
Just a comment on this. As it is right now, the more modules we add to cirros, the bigger the memory requirement.
That is because cirros puts all modules listed into initramfs. Other initramfs solutions only put modules in their initramfs that are needed to reach the "real root", and then loads those modules from lib/modules as necessary.
So, memory footprint for cirros goes up because:
long term solution for this is:
One of solutions could be drop of initramfs (or most of it) and provide disk image as main artifact.
BTW - are there any stats on which files are downloaded?
Artifacts by GitHub download stats:
2463495 cirros-0.4.0-x86_64-disk.img
553531 cirros-0.5.2-x86_64-disk.img
441995 cirros-0.5.1-x86_64-disk.img
409764 cirros-0.5.0-x86_64-disk.img
383977 cirros-0.3.4-x86_64-disk.img
372199 cirros-0.3.5-x86_64-disk.img
143662 cirros-0.4.0-x86_64-uec.tar.gz
130001 cirros-0.5.1-x86_64-uec.tar.gz
92010 cirros-0.3.5-x86_64-uec.tar.gz
89724 cirros-0.3.1-x86_64-uec.tar.gz
79715 cirros-0.3.4-x86_64-uec.tar.gz
60668 cirros-0.5.1-arm-rootfs.img.gz
54529 cirros-0.5.1-aarch64-disk.img
50508 cirros-0.4.0-ppc64le-disk.img
45204 cirros-0.5.2-x86_64-uec.tar.gz
33050 cirros-0.5.2-aarch64-disk.img
32591 cirros-0.3.0-i386-disk.img
18419 cirros-0.4.0-arm-disk.img
16156 cirros-0.3.6-x86_64-disk.img
6032 cirros-0.3.3-x86_64-disk.img
5671 cirros-0.3.4-i386-disk.img
4846 cirros-0.4.0-aarch64-disk.img
4669 cirros-0.5.0-aarch64-disk.img
3427 cirros-0.3.2-x86_64-disk.img
3358 cirros-0.4.0-source.tar.gz
3321 cirros-0.4.0-aarch64-uec.tar.gz
3044 cirros-0.3.0-x86_64-disk.img
2309 cirros-0.4.0-i386-disk.img
2041 cirros-0.3.4-source.tar.gz
Looks like fetching kernel/initramfs files is not popular - people mostly want disk images.
Code used:
#!/usr/bin/python3
import requests
r = requests.get('https://api.github.com/repos/cirros-dev/cirros/releases')
for release in r.json():
for artifact in release["assets"]:
print(f"{artifact['download_count']:9}\t{artifact['name']}")
just using the disk image doesn't solve anything. As it works right now, disk images are empty other than /boot. they load the kernel/initramfs with grub and then that copies itself to the disk. so you font save any memory.
i use the initramfs for a lot of things. they're way useful for testing. https://gist.github.com/smoser/a955b8b5fcf1f47b6c32c4f3a0ec9287
On CI we boot with 512MB of memory so everything works.
I did some minimal testing and got interesting results: