hi all, To celebrate a season of ritual overeating, Id like to propose a diet plan for dynamic_debug. dynamic-debug is carrying extra weight/memory in the __dyndbg linker section, which is basically a struct _ddebug array[]. The 5 display oriented fields carry hierarchical data, and since the linker section is ordered, there is lots of repetition in .module .file .function fields. This patch-set: 1) splits struct _ddebug in 2, creating creating _ddebug_callsites with 5 display-fields, which are placed in a new linker section. while this adds indirection, it lets us manage storage of the .site data, letting us keep the bulk of it in compressed form. 2,3) explores run-length-encoding as one alternative to zram, basically throwaway, but for any ensuing discussion. 4) do kconfig bits - needs work 5) at late-init, copy site recs into zram (and save to .zhandle), thereafter .site is "refilled" (when null) from the .zhandle. Updating the _ddebug.site pointers also means we forget the link-time refs to _callsites section, allowing its reclaim later (once I know how). The .site "refill" is by _getsite(); the corresponding _putsite() works: it zs_unmaps ASAP and zeros .site. This means that every pr_debug will map/unmap once, and `cat control` will do so per line. Probably too expensive. But it works. Im seeing 3 pages_per_zspage, on entire section. 6) a hot locking mess. well, maybe not. plenty of uncertainty though. 7) does not work. It changes _putsite() to keep each zs_mapping when the pr_debug is enabled. But it panics in late-init, with BUG sleeping in atomic context. ? dynamic_emit_prefix is in backtrace. disabling all pr_debugs (--kopt \*.dyndbg=-p) gets to root prompt. once there: echo module main +m > /proc/dynamic_debug/control # is ok echo module main +p > /proc/dynamic_debug/control # BUG sleeping invalid context This strongly implicates the dynamic_emit_prefix call chain. It puzzles me that keeping the zs_mapping would cause so much trouble; its not causing more pr_debugs, and they should all be mapped already. But I really dont know what Im doing here.. WAG at possible memory savings: - add 2 pointers (zhandle, site) 56+16 - drop 48 (sizeof _callsite) * num-pr-debugs linker section - replace with 3:1 storage on same - 48 bytes per enabled pr_debug, typically <1% of set IE: dyndbg: 216 modules, 2058 entries and 8640 bytes in ddebug tables, 115248 bytes in __dyndbg section VS: dyndbg: 224 modules, 2015 entries and 8960 bytes in ddebug tables, 80600 bytes in __dyndbg section, 80600 bytes in __dyndbg_callsites section dyndbg: 2015 entries. repeated entries: 1790 module 1668 file 810 func Once __dyndbg_callsites section is reclaimed, %30 savings looks likely. Jim Cromie (7): dyndbg: move struct _ddebug's display fields to new _ddebug_callsite dyndbg: count repetition in __dyndbg_callsite fields. dyndbg: add some code to see alignments of linkage data dyndbg: select ZPOOL,ZS_MALLOC in Kconfig.debug DYNAMIC_DEBUG_CORE dyndbg: replace __dyndbg_callsite section with a zs-pool copy. dyndbg: add locking around zpool-add loop in zpool-init dyndbg: enable 'cache' of active pr_debug callsites include/asm-generic/vmlinux.lds.h | 4 + include/linux/dynamic_debug.h | 42 ++++-- lib/Kconfig.debug | 2 + lib/dynamic_debug.c | 242 +++++++++++++++++++++++++----- 4 files changed, 239 insertions(+), 51 deletions(-) To: linux-mm@xxxxxxxxx Cc: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> -- 2.28.0
