Shrinking the kernel with a hammer

Posted Mar 2, 2018 14:45 UTC (Fri) by seebe (guest, #114212)
Parent article: Shrinking the kernel with a hammer

> All we need to do is enable CONFIG_XIP_KERNEL and the build system will prompt for the desired kernel physical address location in flash.

Since most ARM MMU-based systems are now multiplatform now in the kernel, you need to hack a line in the ARM Kconfig in order to enable CONFIG_XIP_KERNEL for MMU systems...but it will work (for some systems anyway)

> I later (re)discovered that the almost 10-year-old AXFS filesystem (still maintained out of tree) could have been a good fit. I had forgotten about it though, and in any case I prefer to work with mainline code.

One thing that AXFS has (aside from allowing for a larger file system size) is the ability individually select page by page the portions you want to have XIP-ed (uncompressed) and leave the rest as compressed. This is very helpful because there is a lot of executable and const portions in a file that are simple never run, or only run once at startup or shutdown. So, by only XIP-ing the pages you will commonly use, you can reduce the Flash image size while still retaining low runtime RAM usage. There is profiling tool built into the AXFS driver that will tell you what pages were used (by putting some logging code in the page fault handler) so you can record that information and then input it back into the mkfs.axfs tool.

Maybe at some point we can add this type of functionality into cramfs (since trying to mainline AXFS would be much more work).

to post comments

Shrinking the kernel with a hammer

Posted Mar 2, 2018 19:55 UTC (Fri) by npitre (subscriber, #5680) [Link] (1 responses)

The XIP support for CramFS available in Linux v4.15 already has the ability to work with individually selected XIP-ed pages. It's just a matter of adding a profile-based page selection mechanism to mkcramfs.

Right now mkcramfs enables XIP only for pages that correspond to loadable ELF segments that are flagged readable and/or executable, and not writable. That could be easily extended to e.g. media files that are inherently compressed.

Shrinking the kernel with a hammer

Posted Jan 17, 2023 10:18 UTC (Tue) by sammythesnake (guest, #17693) [Link]

[thread necromancy alert!]

Presumably when mkcramfs compresses files/blocks it has a case to store incompressible things unmodified - marking those files/blocks for XIP might be give the bulk of the benefit of a more sophisticated version for a lot less effort...