On Sat, Oct 19, 2024 at 01:45:35PM -0700, Luis Chamberlain wrote: > On Thu, Oct 17, 2024 at 02:08:19PM +0200, Helge Deller wrote: > > 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 > > You're right, I've just referred to that doc and pushed to the new > linux modules [2] modules-next branch. This is also great timing so > that the work that is ongoing for Rust will take this into > consideration as well. I'll just post the test I wrote as separate > thing but it surely can be used to help test some of this later. > > [2] git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git Helge, I went down memory lane and noted Masahiro asked for this to be done in asm so I droped your patches. Feel free to post a new iteration. Luis