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: [email protected]
Cc: Rasmus Villemoes <[email protected]>
--
2.28.0