[PATCH 0/3] dyndbg: WIP semi-viable diet plan ?

[Jim Cromie]

dynamic-debug metadata is bloated; the __dyndbg linker section, filled
by DYNAMIC_DEBUG_METADATA, has 3 fields with 90%, 84%, 45% repeated
values, consuming ~150kb on my laptop.

Instead of an arduous restructuring of the data, lets stuff it into
zram, get whatever compression it gives us for free, and be able to
map and unmap individual records on demand.

Once map/unmap suffices for internal needs, the whole __dyndbg section
can be reclaimed.

>From this, it seems practical to push it into zswap, and then to keep
active/enabled callsites mapped into ram, like a cache.  But thats a
lot of stuff I can only handwave about.  Please fill in details or
call BS.

This patchset makes a decent start down that path, but theres a boatload
of chatter in the commit-logs about options and maybes, and brave
projections about whats possible. Blah Blah.

Theres almost certainly some subtle/ornot thinkos.
Please point them out.
I probably have some terminology cleanup to do too.
I punted with lazy names a lot & welcome better ones
some // comments too - not for submission

I'll try to summarize here.

- The easiest thing is to stuff whole struct _ddebug contents, into an
  anonymous struct, along with a new zhandle, into a new zpool.  This
  is done in patch 1.  this defers the unionization, so it just
  enlarges the ram footprint.

- patch 2 attempts to distinguish zhandles from pointers, by making
  zhandles odd, and testing with %2.  This works fine before
  unionization, falls over afterwards.

- The unionization is in patch 3, and it works, at least casually.
  The fix-on-2 is to add an explicit flag; is_zhandle, and drop the %2
  test, which fails when it encounters an odd pointer in the __dyndbg
  section.


  the structs/unions must be reworked to actually save any ram

- for non-JUMP_LABEL builds, putting whole struct _ddebug into zram is
  problematic; it means pulling out whole record just to check the
  am-i-printing flag, a horrible cost.

- pulling flags into a separate flags vector would solve that, and
  would be 'tight' on ram; no paholes, good grouping of flags for
  callsites enabled with module=foo function=bar file=buz etc.
  But it creates new ones Im stuck on.

- an 'opaque' descriptor might be the magic needed, but Im pretty
  clueless on how to proceed. Anyone got any pointers to good examples
  in the tree ?
  

This patchset is on top of other dyndbg patches,
which are now in gregkh's char-misc git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.

Jim Cromie (3):
  dyndbg: WIP replace __dyndbg section with a zs-pool copy.
  dyndbg: zhandle+1 plus info tweaks, BUG_ONs
  dyndbg: fixup/correct assumptions re ptr-vals

 include/linux/dynamic_debug.h |   9 ++
 lib/dynamic_debug.c           | 172 ++++++++++++++++++++++++++++++++--
 2 files changed, 171 insertions(+), 10 deletions(-)

-- 
2.26.2