All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses
Date: Thu, 15 Mar 2018 09:29:54 -0700	[thread overview]
Message-ID: <1521131394.22221.25.camel@perches.com> (raw)
In-Reply-To: <20180315161434.GV5453@intel.com>

On Thu, 2018-03-15 at 18:14 +0200, Ville Syrjälä wrote:
> > There's no trade-off in this patch for faster/larger.
> > This patch is simply smaller.  Smaller is better.
> 
> This feels a bit like saying pink is better than red because it's
> more pink.

Silly.  If you can't say smaller total object code that
performs the same task identically is better, I think
we can't discuss much of anything about code together.

Any printk related mechanism is not fast-path so any
icache dilution isn't an issue.

> That said, I'm not arguing against this patch as such. Making things
> smaller "just because" usually doesn't cause problems.

It seems more like you haven't read the patch.

>  But I was
> hoping that we might be after some more tangible gains here, and
> thus pointed out that there may be a better way to achieve even
> bigger gains.

Sure, it's just any such a discussion should not affect
this patch being applied.

This patch reduces the argument count of the drm_printk
(now drm_dbg) call and so is faster to execute even if
the emit test is internal to the drm_dbg function.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Gustavo Padovan <gustavo@padovan.org>,
	Sean Paul <seanpaul@chromium.org>,
	David Airlie <airlied@linux.ie>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses
Date: Thu, 15 Mar 2018 09:29:54 -0700	[thread overview]
Message-ID: <1521131394.22221.25.camel@perches.com> (raw)
In-Reply-To: <20180315161434.GV5453@intel.com>

On Thu, 2018-03-15 at 18:14 +0200, Ville Syrjälä wrote:
> > There's no trade-off in this patch for faster/larger.
> > This patch is simply smaller.  Smaller is better.
> 
> This feels a bit like saying pink is better than red because it's
> more pink.

Silly.  If you can't say smaller total object code that
performs the same task identically is better, I think
we can't discuss much of anything about code together.

Any printk related mechanism is not fast-path so any
icache dilution isn't an issue.

> That said, I'm not arguing against this patch as such. Making things
> smaller "just because" usually doesn't cause problems.

It seems more like you haven't read the patch.

>  But I was
> hoping that we might be after some more tangible gains here, and
> thus pointed out that there may be a better way to achieve even
> bigger gains.

Sure, it's just any such a discussion should not affect
this patch being applied.

This patch reduces the argument count of the drm_printk
(now drm_dbg) call and so is faster to execute even if
the emit test is internal to the drm_dbg function.

  reply	other threads:[~2018-03-15 16:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 22:02 [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses Joe Perches
2018-03-13 23:33 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-03-14  2:16 ` ✓ Fi.CI.IGT: " Patchwork
2018-03-15 13:22 ` [PATCH] " Maarten Lankhorst
2018-03-15 13:22   ` Maarten Lankhorst
2018-03-15 14:48   ` Joe Perches
2018-03-15 14:48     ` Joe Perches
2018-03-15 13:30 ` Ville Syrjälä
2018-03-15 13:30   ` Ville Syrjälä
2018-03-15 14:04   ` Maarten Lankhorst
2018-03-15 14:04     ` Maarten Lankhorst
2018-03-15 15:05     ` Ville Syrjälä
2018-03-15 15:05       ` Ville Syrjälä
2018-03-15 15:17       ` Joe Perches
2018-03-15 15:37         ` Ville Syrjälä
2018-03-15 15:37           ` Ville Syrjälä
2018-03-15 15:44           ` Joe Perches
2018-03-15 15:44             ` Joe Perches
2018-03-15 16:14             ` Ville Syrjälä
2018-03-15 16:14               ` Ville Syrjälä
2018-03-15 16:29               ` Joe Perches [this message]
2018-03-15 16:29                 ` Joe Perches
2018-03-16  7:41 ` Daniel Vetter
2018-03-16  7:41   ` Daniel Vetter
2018-03-16 12:29   ` Joe Perches
2018-03-19 13:53     ` Daniel Vetter
2018-03-19 13:53       ` Daniel Vetter

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=1521131394.22221.25.camel@perches.com \
    --to=joe@perches.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@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.