New blog post:
Executing Linux applications on a Raspberry Pi in less than 3.5s from power-up! 🚀🏎️
(and other power saving tricks)
https://kittenlabs.de/blog/2024/09/01/extreme-pi-boot-optimization/
=> More informations about this toot | More toots from manawyrm@chaos.social
@manawyrm cool stuff! Have you tried with kernel compression through lz4, I.e., CONFIG_KERNEL_LZ4 ? Iirc, that beat the default gzip decompression very solidly in speed. You might also want to try _ZSTD, as I suspect the lower decompression speed of that might balance with the potentially higher compression ratio.
=> More informations about this toot | More toots from funkylab@mastodon.social
@funkylab I‘ve played around with kernel compression, but the extra energy required to decompress the kernel is harmful in my application.
In a less power constrained application, there might be some benefit, yeah!
A hardcore solution would be to write a custom minimal bootloader to move the kernel load away from the GPU and onto the CPU.
I‘m not that desperate yet, but it might help :)
=> More informations about this toot | More toots from manawyrm@chaos.social
@manawyrm that's why I ask: lz4 decompression is (at least on x86) so much faster that it's hard for me to imagine it using the same energy as gzip decompression! But if your tests show that's not the case, then my takeaway is that more hardware-compatible unpackers really are faster by giving the CPU fewer opportunities to do nothing and hence run with less power. Nice lesson!
=> More informations about this toot | More toots from funkylab@mastodon.social
@funkylab At that point, the other CPU cores also aren‘t up yet. That limits the performance somewhat.
=> More informations about this toot | More toots from manawyrm@chaos.social
@manawyrm I don't think more cores would even help with lz4
=> More informations about this toot | More toots from funkylab@mastodon.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini