On Fri, Dec 11, 2020 at 8:34 AM Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote:
drm's debug system uses distinct categories of debug messages, mapped to bits in drm.debug. Currently, code does a lot of unlikely bit-mask checks on drm.debug (in drm_debug_enabled), we can use dynamic debug instead, and get all that jump_label goodness.
Is there an actual need to go through dyndbg and do all this stringy stuff, or would just eg. a static keys array for the debug categories get us the benefits of jump_label?
You certainly can strip the car, take the engine. but you might need some of the drivetrain too. maybe you want to skip the heated seats ? dyndbg has some stuff you dont need, for sure.
for one, its heavy on data per callsite, with a static-key and overhead for each.
But Id be wary that the jump-label code-patching is a slow path, so trying to change hundreds of jump-sites with one static-key field may run into problems with long lock hold times, etc.
There is a batching mechanism built-in to the jump-label stuff somewhere, my impression is that it amortized system-wide syncs while being RT aware.
I've been working on trimming dyndbg down, at least the memory. I'll be sending it out shortly, but heres a preview:
Subject: [RFC PATCH v2 0/7] dynamic debug diet plan
V2 is a rethought diet plan for dyndbg (I meant -v1 as rfc).
at highest level, patchset does: 1- move struct _ddebug "selector" fields to new struct _ddebug_callsite 2- make ddebug_callsites optional, good for some users 3- allow dropping callsites by those users.
1-v2. Rasmus noted that I shouldn't move format with the other fields, and I realized that the "module:function:line" dynamic prefixes are ultimately just log decorations, and are not needed for certain use cases, including drm (with category -> prefix adaptation).
The drm use case:
- can benefit from jump-labels to avoid drm_debug_enabled() - can map categories to format-prefixes: "drm:core:" "drm:kms:" etc - can use dynamic_debug_exec_queries("format ^drm:core: +p", NULL) - drm + amdgpu have ~3200 drm-debugs, drm + i915 have ~1600
If drm dropped optional site info, net 16 bytes saved / callsite, maybe more...
dropping optional info : module file func means loss of log "decorations" and slimmer contents of control file. uncategorized pr-debugs can be avoided when dropping callsites. Even with dropped info, format, line, module queries can select individual sites precisely.
As of now, we still need the __dyndbg_callsites linker section; the 3-drop is just a forget-the-addy, not a kfree.
But compression is possible. v1 tried using zram, with mixed success. v2 is a better foundation to re-try the zram.