On Wed, 23 Sep 2026 16:34:24 -0600 Jim Cromie <[email protected]> wrote:
> The drm subsystem has *lots* of debug statements, in 11 categories:
>
> $> git grep '\w*_dbg' drivers/gpu/drm/ | wc
> 5663 30159 542864
Methinks this regexp was overly promiscuous, but point taken.
> $> git grep 'DRM_DEBUG\w*' drivers/gpu/drm/ | wc
> 2206 12834 202332
>
> All of these are bit-tests on __drm_debug, exposed to users as
> /sys/module/drm/parameters/debug. Many of these are done often;
> vblank is done ~100/sec for some displays. Over the uptime of many
> boxes, this is a lot of cpu cycles on bits that are almost always off.
A __test_bit (or |) every 10ms sounds quite negligible?
Especially if __drm_debug is __read_mostly. Which it isn't, afaict.
Um, low-hanging fruit?
> Dynamic-debug excels at replacing such tests with NOOPs (via static
> keys). Classmaps was devised to bring that 0-off-cost to drm's
> categories.
>
> Classmaps-v1 went into the kernel in Sept 2022, in 2 chunks:
> b7b4eebdba7b..6ea3bf466ac6 # core dyndbg changes
> 0406faf25fb1..ee7d633f2dfb # drm adoption
>
> Sadly DRM-CI found a regression during init with drm.debug=<initval>;
> the static-keys underneath the drm-dbgs in drm.ko got enabled, but
> those in drivers & helpers did not.
>
> So in Feb 2023, it got pulled:
> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
>
> Root Problem:
>
> DECLARE_DYNDBG_CLASSMAP defined the classmap, but its repeated use in
> both core and drivers violated a K&R rule "define once, refer
> afterwards". This flaw resulted in a regression; with drm.debug=0xFF
> boot arg, drm-core got enabled, but drivers/helpers did not.
>
> This patchset replaces DECLARE_DYNDBG_CLASSMAP with:
> - DYNAMIC_DEBUG_CLASSMAP_DEFINE (invoked once in the exporting module)
> - DYNAMIC_DEBUG_CLASSMAP_USE (invoked repeatedly in drivers & helpers)
>
> _DEFINE exports the classmap it creates (in drm.ko), and other modules
> _USE the classmap. The _USE adds a record referencing the _DEFINEd (&
> exported) classmap in a 2nd __dyndbg_class_users section.
>
> At modprobe, dyndbg scans the new section after __dyndbg_class_maps,
> follows the linkage to the _DEFINEr module, finds the (optional)
> kernel-param controlling the classmap, examines its drm.debug=<initval>,
> and applies it to the module being initialized.
>
> To recapitulate the multi-module problem wo DRM involvement, we add:
>
> - tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh:
> Alters pr_debugs in builtins and test modules,
> checks results against checksums of expected results
>
> - lib/test_dynamic_debug.c & test_dynamic_debug_submod.c:
> Builds parent & _submod modules with _DEFINE and _USE inside #if/#else
> blocks, reproducing the 2-module scenario under selftests.
So what I'm understanding is that this series presently has no effect
upon DRM?
What subsystems *does* it affect?
Sashiko had quite a bit to say. It hasn't quite completed at present.
https://sashiko.dev/#/patchset/[email protected]
