From: Jim Cromie <jim.cromie@gmail.com> To: jbaron@akamai.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Cc: Jim Cromie <jim.cromie@gmail.com> Subject: [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Date: Tue, 31 Aug 2021 14:21:31 -0600 [thread overview] Message-ID: <20210831202133.2165222-7-jim.cromie@gmail.com> (raw) In-Reply-To: <20210831202133.2165222-1-jim.cromie@gmail.com> Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" branch. Then convert the "dyndbg" branch's code to a macro, so that its pr_debug() get its callsite info from the invoking function, instead of from drm_debug_enabled() itself. This gives us unique callsite info for the 8 remaining users of drm_debug_enabled(), and lets us enable them individually to see how much logging traffic they generate. The oft-visited callsites can then be reviewed for runtime cost and possible optimizations. Heres what we get: bash-5.1# modprobe drm dyndbg: 384 debug prints in module drm bash-5.1# grep todo: /proc/dynamic_debug/control drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\012" At quick glance, edid won't qualify, drm_print might, drm_vblank is strongest chance, maybe atomic-ioctl too. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> --- include/drm/drm_print.h | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index 973443040561..03f9ae83fade 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -378,6 +378,11 @@ enum drm_debug_category { #define DRM_DBG_CAT_DP DRM_UT_DP #define DRM_DBG_CAT_DRMRES DRM_UT_DRMRES +static inline bool drm_debug_enabled(enum drm_debug_category category) +{ + return unlikely(__drm_debug & category); +} + #else /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ /* join prefix+format in cpp so dyndbg can see it */ @@ -397,12 +402,13 @@ enum drm_debug_category { #define DRM_DBG_CAT_DP "drm:dp: " #define DRM_DBG_CAT_DRMRES "drm:res: " /* not in MODULE_PARM_DESC */ -#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ +#define drm_debug_enabled(category) \ + ({ \ + pr_debug("todo: maybe avoid via dyndbg\n"); \ + unlikely(__drm_debug & category); \ + }) -static inline bool drm_debug_enabled(enum drm_debug_category category) -{ - return unlikely(__drm_debug & category); -} +#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ /* * struct device based logging -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com> To: jbaron@akamai.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Cc: Jim Cromie <jim.cromie@gmail.com> Subject: [Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Date: Tue, 31 Aug 2021 14:21:31 -0600 [thread overview] Message-ID: <20210831202133.2165222-7-jim.cromie@gmail.com> (raw) In-Reply-To: <20210831202133.2165222-1-jim.cromie@gmail.com> Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" branch. Then convert the "dyndbg" branch's code to a macro, so that its pr_debug() get its callsite info from the invoking function, instead of from drm_debug_enabled() itself. This gives us unique callsite info for the 8 remaining users of drm_debug_enabled(), and lets us enable them individually to see how much logging traffic they generate. The oft-visited callsites can then be reviewed for runtime cost and possible optimizations. Heres what we get: bash-5.1# modprobe drm dyndbg: 384 debug prints in module drm bash-5.1# grep todo: /proc/dynamic_debug/control drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo: maybe avoid via dyndbg\012" drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\012" At quick glance, edid won't qualify, drm_print might, drm_vblank is strongest chance, maybe atomic-ioctl too. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> --- include/drm/drm_print.h | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index 973443040561..03f9ae83fade 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -378,6 +378,11 @@ enum drm_debug_category { #define DRM_DBG_CAT_DP DRM_UT_DP #define DRM_DBG_CAT_DRMRES DRM_UT_DRMRES +static inline bool drm_debug_enabled(enum drm_debug_category category) +{ + return unlikely(__drm_debug & category); +} + #else /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ /* join prefix+format in cpp so dyndbg can see it */ @@ -397,12 +402,13 @@ enum drm_debug_category { #define DRM_DBG_CAT_DP "drm:dp: " #define DRM_DBG_CAT_DRMRES "drm:res: " /* not in MODULE_PARM_DESC */ -#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ +#define drm_debug_enabled(category) \ + ({ \ + pr_debug("todo: maybe avoid via dyndbg\n"); \ + unlikely(__drm_debug & category); \ + }) -static inline bool drm_debug_enabled(enum drm_debug_category category) -{ - return unlikely(__drm_debug & category); -} +#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */ /* * struct device based logging -- 2.31.1
next prev parent reply other threads:[~2021-08-31 20:21 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-31 20:21 [PATCH v7 0/8] use DYNAMIC_DEBUG to implement DRM.debug Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 20:21 ` [PATCH v7 1/8] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 20:21 ` [PATCH v7 2/8] dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 20:21 ` [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-09-03 11:07 ` Tvrtko Ursulin 2021-09-03 19:22 ` jim.cromie 2021-09-03 19:22 ` jim.cromie 2021-09-06 12:26 ` Tvrtko Ursulin 2021-09-06 17:41 ` jim.cromie 2021-09-07 15:14 ` Tvrtko Ursulin 2021-09-07 17:26 ` jim.cromie 2021-09-07 17:26 ` jim.cromie 2021-08-31 20:21 ` [PATCH v7 4/8] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 20:21 ` [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-09-03 11:15 ` Tvrtko Ursulin 2021-09-03 21:57 ` jim.cromie 2021-09-03 21:57 ` jim.cromie 2021-09-06 10:20 ` Tvrtko Ursulin 2021-09-06 18:24 ` jim.cromie 2021-09-06 18:24 ` jim.cromie 2021-08-31 20:21 ` Jim Cromie [this message] 2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Jim Cromie 2021-09-05 18:50 ` jim.cromie 2021-09-05 18:50 ` [Intel-gfx] " jim.cromie 2021-09-05 18:50 ` jim.cromie 2021-08-31 20:21 ` [PATCH v7 7/8] amdgpu_ucode: reduce number of pr_debug calls Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 20:21 ` [PATCH v7 8/8] nouveau: fold multiple DRM_DEBUG_DRIVERs together Jim Cromie 2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie 2021-08-31 21:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for use DYNAMIC_DEBUG to implement DRM.debug (rev2) Patchwork 2021-08-31 21:37 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2021-08-31 22:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-08-31 23:38 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-09-03 0:31 ` jim.cromie 2021-09-03 11:29 ` Tvrtko Ursulin 2021-09-03 13:01 ` Petri Latvala 2021-09-05 17:35 ` jim.cromie 2021-09-06 10:14 ` Tvrtko Ursulin 2021-09-06 10:04 ` Tvrtko Ursulin 2021-09-06 11:25 ` Petri Latvala 2021-09-07 4:13 ` Gupta, Anshuman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210831202133.2165222-7-jim.cromie@gmail.com \ --to=jim.cromie@gmail.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=intel-gvt-dev@lists.freedesktop.org \ --cc=jbaron@akamai.com \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.