From: Michel Thierry <michel.thierry@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/i915: Track GEN6 page table usage
Date: Thu, 19 Mar 2015 17:16:00 +0000 [thread overview]
Message-ID: <550B0450.4070203@intel.com> (raw)
In-Reply-To: <20150319161310.GY31422@phenom.ffwll.local>
On 3/19/2015 4:13 PM, Daniel Vetter wrote:
> On Mon, Mar 16, 2015 at 04:00:56PM +0000, Michel Thierry wrote:
>> +static inline uint32_t i915_pte_count(uint64_t addr, size_t length,
>> + uint32_t pde_shift)
>> +{
>> + const uint64_t mask = ~((1 << pde_shift) - 1);
>> + uint64_t end;
>> +
>> + BUG_ON(length == 0);
>> + BUG_ON(offset_in_page(addr|length));
>> +
>> + end = addr + length;
>> +
>> + if ((addr & mask) != (end & mask))
>> + return NUM_PTE(pde_shift) - i915_pte_index(addr, pde_shift);
>> +
>> + return i915_pte_index(end, pde_shift) - i915_pte_index(addr, pde_shift);
>> +}
> Also this is an impressively big function, I'm pretty sure too big to get
> inlined reasonable. Can you please follow-up with a patch to move this
> into i915_gem_gtt.c?
>
> General rule for static inline is that either
> a) function body is obviously smaller when inlined in code-size
> b) patch comes with solid justification in the form of hard performance
> data that the inline is better
>
> If neither applies drop the static inline. Generally these
> microoptimizations are premature and only result in binary code size
> increase. Which tends to thrash instruction caches and actually reduces
> performance.
>
> Iirc there's more of that going on in this series, so perhaps do a
> follow-up for all of these.
> Thanks, Daniel
That's the biggest one, the rest will be 2-3 lines long. I'll send a
follow-up patch for this one.
Thanks
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-03-19 17:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 16:00 [PATCH 0/5] Gen6/7 PPGTT dynamic page alloc prep work Michel Thierry
2015-03-16 16:00 ` [PATCH 1/5] drm/i915: page table generalizations Michel Thierry
2015-03-16 16:00 ` [PATCH 2/5] drm/i915: Extract context switch skip and add pd load logic Michel Thierry
2015-03-16 16:00 ` [PATCH 3/5] drm/i915: Track GEN6 page table usage Michel Thierry
2015-03-19 16:08 ` Daniel Vetter
2015-03-19 16:13 ` Daniel Vetter
2015-03-19 17:16 ` Michel Thierry [this message]
2015-03-16 16:00 ` [PATCH 4/5] drm/i915: Track page table reload need Michel Thierry
2015-03-19 9:01 ` Mika Kuoppala
2015-03-19 11:26 ` Michel Thierry
2015-03-19 12:53 ` [PATCH] " Michel Thierry
2015-03-16 16:00 ` [PATCH 5/5] drm/i915: Initialize all contexts Michel Thierry
2015-03-16 21:39 ` shuang.he
2015-03-19 13:32 ` [PATCH 0/5] Gen6/7 PPGTT dynamic page alloc prep work Mika Kuoppala
2015-03-19 16:21 ` 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=550B0450.4070203@intel.com \
--to=michel.thierry@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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.