All of lore.kernel.org
 help / color / mirror / Atom feed
From: jim.cromie@gmail.com
To: Jason Baron <jbaron@akamai.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	amd-gfx mailing list <amd-gfx@lists.freedesktop.org>,
	intel-gvt-dev@lists.freedesktop.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v7 6/8] drm_print: instrument drm_debug_enabled
Date: Sun, 5 Sep 2021 12:50:48 -0600	[thread overview]
Message-ID: <CAJfuBxwqdy888_v7a6U5BYPZxDkQAB4SLPdFyEv+MW98ByNuQg@mail.gmail.com> (raw)
In-Reply-To: <20210831202133.2165222-7-jim.cromie@gmail.com>

On Tue, Aug 31, 2021 at 2:21 PM Jim Cromie <jim.cromie@gmail.com> wrote:
>
> 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>
> ---

heres 120 seconds of enabled todos, from this patch

[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
[jimc@frodo wk-next]$ sudo su -c 'echo format ^todo: +pfml >
/proc/dynamic_debug/control;  sleep 120; echo format ^todo: -p >
/proc/dynamic_debug/control'
[sudo] password for jimc:
[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
 > todo-120-log
[jimc@frodo wk-next]$ wc todo-120-log
  228  2516 24066 todo-120-log

so overall thats not too much work, not so many bitchecks as to be
worth avoiding.

I think I'll try hitting it with my new igt-tools hammer, see what breaks :-)


[jimc@frodo wk-next]$ hsto todo-120-log
120 :  drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal:787:
todo: maybe avoid via dyndbg
40 :  i915:process_csb:1904: todo: maybe avoid via dyndbg
20 :  drm:drm_vblank_restore:1491: todo: maybe avoid via dyndbg
20 :  drm:drm_crtc_accurate_vblank_count:410: todo: maybe avoid via dyndbg
20 :  i915:skl_print_wm_changes:6068: todo: maybe avoid via dyndbg
2 :  dyndbg: applied: func="" file="" module="" format="^todo:" lineno=0-0
2 :  dyndbg: parsed: func="" file="" module="" format="^todo:" lineno=0-0
1 :  dyndbg: split into words: "format" "^todo:" "-p"
1 :  dyndbg: split into words: "format" "^todo:" "+pfml"
1 :  dyndbg: query 0: "format ^todo: -p" mod:*
1 :  dyndbg: query 0: "format ^todo: +pfml" mod:*

WARNING: multiple messages have this Message-ID (diff)
From: jim.cromie@gmail.com
To: Jason Baron <jbaron@akamai.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	 LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	 amd-gfx mailing list <amd-gfx@lists.freedesktop.org>,
	intel-gvt-dev@lists.freedesktop.org,
	 Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled
Date: Sun, 5 Sep 2021 12:50:48 -0600	[thread overview]
Message-ID: <CAJfuBxwqdy888_v7a6U5BYPZxDkQAB4SLPdFyEv+MW98ByNuQg@mail.gmail.com> (raw)
In-Reply-To: <20210831202133.2165222-7-jim.cromie@gmail.com>

On Tue, Aug 31, 2021 at 2:21 PM Jim Cromie <jim.cromie@gmail.com> wrote:
>
> 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>
> ---

heres 120 seconds of enabled todos, from this patch

[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
[jimc@frodo wk-next]$ sudo su -c 'echo format ^todo: +pfml >
/proc/dynamic_debug/control;  sleep 120; echo format ^todo: -p >
/proc/dynamic_debug/control'
[sudo] password for jimc:
[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
 > todo-120-log
[jimc@frodo wk-next]$ wc todo-120-log
  228  2516 24066 todo-120-log

so overall thats not too much work, not so many bitchecks as to be
worth avoiding.

I think I'll try hitting it with my new igt-tools hammer, see what breaks :-)


[jimc@frodo wk-next]$ hsto todo-120-log
120 :  drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal:787:
todo: maybe avoid via dyndbg
40 :  i915:process_csb:1904: todo: maybe avoid via dyndbg
20 :  drm:drm_vblank_restore:1491: todo: maybe avoid via dyndbg
20 :  drm:drm_crtc_accurate_vblank_count:410: todo: maybe avoid via dyndbg
20 :  i915:skl_print_wm_changes:6068: todo: maybe avoid via dyndbg
2 :  dyndbg: applied: func="" file="" module="" format="^todo:" lineno=0-0
2 :  dyndbg: parsed: func="" file="" module="" format="^todo:" lineno=0-0
1 :  dyndbg: split into words: "format" "^todo:" "-p"
1 :  dyndbg: split into words: "format" "^todo:" "+pfml"
1 :  dyndbg: query 0: "format ^todo: -p" mod:*
1 :  dyndbg: query 0: "format ^todo: +pfml" mod:*

  reply	other threads:[~2021-09-05 18:51 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 ` [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-09-05 18:50   ` jim.cromie [this message]
2021-09-05 18:50     ` 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=CAJfuBxwqdy888_v7a6U5BYPZxDkQAB4SLPdFyEv+MW98ByNuQg@mail.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: link
Be 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.