linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jim.cromie@gmail.com
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	David Airlie <airlied@linux.ie>, Jason Baron <jbaron@akamai.com>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug
Date: Thu, 17 Dec 2020 14:31:02 -0700	[thread overview]
Message-ID: <CAJfuBxwjW107Hx46_MB5F9wR3AXxcS02fAHjF_new4sWwcGKRQ@mail.gmail.com> (raw)
In-Reply-To: <X9OQkyWYBpBb+PDC@intel.com>

On Fri, Dec 11, 2020 at 8:34 AM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote:
> > drm's debug system uses distinct categories of debug messages, mapped
> > to bits in drm.debug.  Currently, code does a lot of unlikely bit-mask
> > checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
> > instead, and get all that jump_label goodness.

> Is there an actual need to go through dyndbg and do all this stringy
> stuff, or would just eg. a static keys array for the debug categories
> get us the benefits of jump_label?
>

You certainly can strip the car, take the engine.
but you might need some of the drivetrain too.
maybe you want to skip the heated seats ?
dyndbg has some stuff you dont need, for sure.

for one, its heavy on data per callsite, with a static-key and
overhead for each.

But Id be wary that the jump-label code-patching is a slow path,
so trying to change hundreds of jump-sites with one static-key field
may run into problems with long lock hold times, etc.

There is a batching mechanism built-in to the jump-label stuff somewhere,
my impression is that it amortized system-wide syncs while being RT aware.


I've been working on trimming dyndbg down, at least the memory.
I'll be sending it out shortly, but heres a preview:


Subject: [RFC PATCH v2 0/7] dynamic debug diet plan

V2 is a rethought diet plan for dyndbg (I meant -v1 as rfc).

at highest level, patchset does:
1- move struct _ddebug "selector" fields to new struct _ddebug_callsite
2- make ddebug_callsites optional, good for some users
3- allow dropping callsites by those users.

1-v2. Rasmus noted that I shouldn't move format with the other fields,
and I realized that the "module:function:line" dynamic prefixes are
ultimately just log decorations, and are not needed for certain use
cases, including drm (with category -> prefix adaptation).

The drm use case:

- can benefit from jump-labels to avoid drm_debug_enabled()
- can map categories to format-prefixes: "drm:core:" "drm:kms:" etc
- can use dynamic_debug_exec_queries("format ^drm:core: +p", NULL)
- drm + amdgpu have ~3200 drm-debugs, drm + i915 have ~1600

If drm dropped optional site info, net 16 bytes saved / callsite, maybe more...

dropping optional info : module file func means loss of log "decorations"
and slimmer contents of control file.  uncategorized pr-debugs can be
avoided when dropping callsites.   Even with dropped info,
format, line, module queries can select individual sites precisely.

As of now, we still need the __dyndbg_callsites linker section; the
3-drop is just a forget-the-addy, not a kfree.

But compression is possible. v1 tried using zram, with mixed success.
v2 is a better foundation to re-try the zram.

  reply	other threads:[~2020-12-17 21:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  3:53 [RFC PATCH 0/2] drm: use dynamic_debug Jim Cromie
2020-12-04  3:53 ` [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug Jim Cromie
2020-12-04 15:42   ` Ville Syrjälä
2020-12-04 19:20     ` jim.cromie
2020-12-11 15:30   ` Ville Syrjälä
2020-12-17 21:31     ` jim.cromie [this message]
2020-12-04  3:53 ` [RFC PATCH 2/2] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt Jim Cromie

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=CAJfuBxwjW107Hx46_MB5F9wR3AXxcS02fAHjF_new4sWwcGKRQ@mail.gmail.com \
    --to=jim.cromie@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jbaron@akamai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    --subject='Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).