On Wed, Sep 23, 2026 at 4:53 PM Andrew Morton <[email protected]> wrote:
>
> 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?
>
__drm_debug certainly qualifies.
I will send the patch, separately.
patch 37 adds a +c flag, to count invocations of flagged callsites
it counted 5M calls in 60 sec. or 83 KHz.
That seems "fast-ish" at least,
perhaps worthy of a static-key over a __read_mostly
> > 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?
I have 2-3 DRM adaptation patches,
then a single 1-liner patch per driver,
to get DRM using the new API.
39 patches seemed big enough for now,
if you'd like the rest tacked on, Im happy to do so.
> 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]
