From: jim.cromie@gmail.com
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: 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 5/8] drm_print: add choice to use dynamic debug in drm-debug
Date: Mon, 6 Sep 2021 12:24:46 -0600 [thread overview]
Message-ID: <CAJfuBxxQ-dNWHv1VGu7Hh705wZbxmsStDa_-cc=63fDtNZiyjg@mail.gmail.com> (raw)
In-Reply-To: <1aabb5c0-eef9-a483-2631-25726c9dc268@linux.intel.com>
> I'll try to extract the "executive summary" from this, you tell me if I
> got it right.
>
> So using or not using dynamic debug for DRM debug ends up being about
> shifting the cost between kernel binary size (data section grows by each
> pr_debug call site) and runtime conditionals?
Yes.
> Since the table sizes you mention seem significant enough, I think that
> justifies existence of DRM_USE_DYNAMIC_DEBUG. It would probably be a
> good idea to put some commentary on that there. Ideally including some
> rough estimates both including space cost per call site and space cost
> for a typical distro kernel build?
yeah, agreed. I presume you mean in Kconfig entry,
since commits have some size info now - I have i915, amdgpu, nouveau;
I can see some prose improvements for 5/8
> Regards,
>
> Tvrtko
thanks
Jim
next prev parent reply other threads:[~2021-09-06 18:26 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 [this message]
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
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='CAJfuBxxQ-dNWHv1VGu7Hh705wZbxmsStDa_-cc=63fDtNZiyjg@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 \
--cc=tvrtko.ursulin@linux.intel.com \
/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.