We need to check memory requirements

[hrw]

On CI we boot with 512MB of memory so everything works.

I did some minimal testing and got interesting results:

arch	mach type	bootloader	memory needed (MB)
aarch64	virt	uefi	256
arm	virt	direct kernel	128
ppc64	pseries	default	128
ppc64le	pseries	default	256
x86-64	i440fx	bios	128
x86-64	i440fx	uefi	256
x86-64	q35	bios	128
x86-64	q35	uefi	256

[hrw]

I think that once we find out values by hand then set of CI tests needs to be added.

[SeanMooney]

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 ?

[hrw]

For CirrOS 0.6 instance memory requirements look like that:

• 128MB
  • arm (virt with direct kernel boot)
  • x86_64 (bios boot)
• 192MB
  • aarch64 (virt with direct kernel boot)
• 256MB
  • ppc64le
  • x86_64 (uefi)
• 272MB
  • aarch64 (virt with uefi)

Notes:

• ppc64le requires 256MB alignment
• aarch64 kernel oops on 128MB ram
• aarch64/uefi fails on 256MB ram (on Fedora 36 host)

[smoser]

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:

• new kernels : over time new kernels just need more ram
• buildroot updates : over time...
• new programs added (update things for 0.6.x work #82)
• new modules added (b08eaea, 034d2e2, 87b6564, Add sctp module #75).

long term solution for this is:

• be more picky about what is allowed to be added
• store modules in disk and possibly download
• add some sort "package manager" to download new programs

[hrw]

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?

[hrw]

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.

[hrw]

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']}")

[smoser]

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