From: Richard Mortimer <richm@xxxxxxxxxxxxxxx> Date: Fri, 14 Jan 2011 16:08:30 +0000 [ Frederic, Steven, Ingo, the short version of the story is that we need to make it such that the _ftrace_events section is aligned properly for 64-bit systems, and in particular that GCC can see this too. Otherwise GCC thinks 64-bit words will be unaligned and we get all kinds of funky relocations being used in modules on sparc64 that really there is never any reason to see. ] > They seem to come from scsi.o at > > .LLC51: > .asciz "scsi_eh_wakeup" > .section _ftrace_events,"aw",@progbits > .align 4 > .type event_scsi_eh_wakeup, #object > .size event_scsi_eh_wakeup, 136 > event_scsi_eh_wakeup: > .skip 16 > .uaxword event_class_scsi_eh_wakeup > .uaxword .LLC51 > .skip 8 > .skip 40 > .uaxword ftrace_event_type_funcs_scsi_eh_wakeup > .uaxword print_fmt_scsi_eh_wakeup > .skip 40 These ".uaxword" emissions are a bug, and if we let them stand then ftrace events are going to load every long word object using a sequence of byte-sized accesses. This will absolutely kill performance. This is exactly why I wanted to find out why this started happening out of nowhere, instead of blindly adding support for new relocation types to the sparc module loader. The set of relocations supported by the sparc module loading code is not meant to be "all relocations which are legal" but rather it's meant to support the most minimum set of relocations that the kernel actually _needs_ and should be making use of. I think the problem we have here is that the _ftrace_events section is not aligned sufficiently. That ".align 4" mnemonic is a good indication of this. It should at least "8" on sparc64. So we need to figure out why that is happening, and fix that instead. Thanks. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
