Can't configure hugepages kernel args, image factory changes order in kernel command line.

[kdish]

Trying to generate a bare metal image of talos 1.8.1 with the following extra kernel args
hugepagesz=1G hugepages=32 hugepagesz=2M hugepages=1024

All arguments entered are present in the generated kernel command line (and image), but they are not in the same order. (The hugepage settings require that the size and count are in sequence).

The resulting kernel command line from image factory looks like this:
talos.platform=metal console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 hugepagesz=1G hugepagesz=2M hugepages=32 hugepages=1024

This results in hugepages being disabled at boot.

[smira]

Yes, this is a bug, but partially also the way Talos handles kernel command line, so fixing it won't be easy, but we should fix that.

[kdish]

Thanks for accepting the report! Is there any possible workaround i could try? I'm trying to run an application that needs these hugepage settings and I would prefer to do it with talos....

[kdish]

For anyone else running into this issue, I managed to get hugepages working by mounting the /boot partition from the generated image and editing the kernel command line in grub/grub.cfg

After booting on my modified image I get:
$ kubectl describe nodes | grep -A 8 Allocatable | grep huge
hugepages-1Gi: 32Gi
hugepages-2Mi: 2Gi

Which is what I want...
Please let me know if there are any fundamental problems with this approach, otherwise I will go with this until the bug is fixed.

[smira]

Yes, this is the only workaround unless there's any other way to configure hugepages.

[smira]

https://docs.kernel.org/admin-guide/mm/hugetlbpage.html there seems to be multiple ways to configure hugepages, so it might be that you can get around by using sysfs and machine configuration.

[kdish]

Thanks. I'll look into the docs.