On 23/04/2019 21.36, Andrew Morton wrote: > On Tue, 23 Apr 2019 17:37:33 +0200 Christophe Leroy <christophe.le...@c-s.fr> > wrote: > >>> --- a/arch/powerpc/Kconfig >>> +++ b/arch/powerpc/Kconfig >>> @@ -155,6 +155,7 @@ config PPC >>> select BUILDTIME_EXTABLE_SORT >>> select CLONE_BACKWARDS >>> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN >>> + select DYNAMIC_DEBUG_RELATIVE_POINTERS if PPC64 >> >> Why only PPC64 ? Won't it work with PPC32 ? Or would it be >> counter-performant on 32 bits ? > > Ditto arm and i386? >
It's pointless on 32-bit platforms - I'm replacing absolute const char* pointers with a relative s32 offset from the _ddebug descriptor, so if sizeof(void*)==4 there's no gain. And yes, the current implementation also wouldn't work out-of-the-box for 32-bit platforms, since the asm needs to know how to properly initialize a whole struct _ddebug, which (often) contains a static_key, which in turn contains a pointer member, which both affects its size as well as its placement inside _ddebug. The C code in dynamic_debug.c would likely Just Work, but there's no point in complicating the asm part for no gain, so there are static_assert()s in place to ensure BITS_PER_LONG==64 (as well as checking the various offsetof()s etc.). [I don't think performance matters at all, it's one extra addition to access these fields, and that is only done in the rare cases where someone interacts with the dynamic_debug/control sysfs file, and when one of the activated pr_debug()s is actually hit (so a few extra instructions drown in the printk overhead).] I do now see that PPC64 does not select GENERIC_BUG_RELATIVE_POINTERS, so maybe this scheme simply doesn't work on PPC64, or nobody has done the work to reduce the sizeof(struct bug_entry) on PPC64? As I said, I've only compile-tested arm64 and ppc64. Rasmus
