[PATCH 0/7] WIP dyndbg diet plan, paging Dr Zram.

[Jim Cromie <jim.cromie@gmail.com>]

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@kvack.org
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
-- 
2.28.0