Hi Luis, On 10/17/24 01:21, Luis Chamberlain wrote:
That sounds great. Yeah, the above would be great to test. A while ago I wrote a new modules selftests in order to test possible improvements on find_symbol() but I also did this due to push the limits of the numbers of symbols we could support. I wrote all this to also test the possible 64-bit alignment benefits of __ksymtab_ sections on architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (e.g. ppc64, ppc64le, parisc, s390x,...). [....] I forget what we concluded on Helge Deller's alignement patches, I think there was an idea on how to address the alignment through other means. [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20241016-modules-symtab
I stumbled upon the unaligned-memory-access.rst document [1]. Please read it, as it is a really good document, and the section "Why unaligned access is bad" states: It should be obvious from the above that if your code causes unaligned memory accesses to happen, your code will not work correctly on certain platforms and will cause performance problems on others. With this in mind, you really should apply both of my alignment patches which you currently carry in [0]. For parisc I partly solved the issue by fixing the arch-specific kernel unalignment handler, but every time module sections are stored unaligned, it triggers performance degregation on parisc (and other sensitive platforms). I suggest you apply them unconditionally. Helge [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/unaligned-memory-access.rst
