From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: refactor i915_gem_object_pin_map()
Date: Wed, 20 Apr 2016 10:39:36 +0100 [thread overview]
Message-ID: <57174E58.7070701@intel.com> (raw)
In-Reply-To: <20160419195015.GC14602@nuc-i3427.alporthouse.com>
On 19/04/16 20:50, Chris Wilson wrote:
> On Tue, Apr 19, 2016 at 06:40:07PM +0100, Dave Gordon wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> The recently-added i915_gem_object_pin_map() can be further optimised
>> for "small" objects. To facilitate this, and simplify the error paths
>> before adding the new code, this patch pulls out the "mapping" part of
>> the operation (involving local allocations which must be undone before
>> return) into its own subfunction.
>>
>> The next patch will then insert the new optimisation into the middle of
>> the now-separated subfunction.
>>
>> This reorganisation will probably not affect the generated code, as the
>> compiler will most likely inline it anyway, but it makes the logical
>> structure a bit clearer and easier to modify.
>>
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>> drivers/gpu/drm/i915/i915_gem.c | 61 +++++++++++++++++++++++++++--------------
>> 1 file changed, 40 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index 6ce2c31..fc42be0 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -2396,6 +2396,45 @@ static void i915_gem_object_free_mmap_offset(struct drm_i915_gem_object *obj)
>> return 0;
>> }
>>
>> +/* The 'mapping' part of i915_gem_object_pin_map() below */
>> +static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
>> +{
>> + unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
>> + struct scatterlist *sg = obj->pages->sgl;
>> + struct sg_page_iter sg_iter;
>> + struct page **pages;
>> + unsigned long i = 0;
>> + void *addr = NULL;
>> +
>> + /* A single page can always be kmapped */
>> + if (n_pages == 1)
>> + return kmap(sg_page(sg));
>> +
>> + pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
>> + if (pages == NULL) {
>> + DRM_DEBUG_DRIVER("Failed to get space for pages\n");
>> + return NULL;
>> + }
>> +
>> + for_each_sg_page(sg, &sg_iter, n_pages, 0) {
>> + pages[i] = sg_page_iter_page(&sg_iter);
>
> Just pages[i++] = sg_page_iter_page(&sg_iter);
>
>> + if (++i == n_pages) {
>> + addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
>> + break;
>> + }
>> + }
>> +
>> + /* We should have got here via the 'break' above */
>> + WARN_ON(i != n_pages);
>> + if (addr == NULL)
>> + DRM_DEBUG_DRIVER("Failed to vmap pages\n");
>
> As this is a very, very confused loop.
> -Chris
I tried that approach before, but it was actually more difficult to have
tidy error-checking that way (remembering that we must always free the
pages array, so don't really want an early return).
Here, putting the vmap() inside the final iteration of the loop means
that we automatically leave "addr" as NULL if we don't reach the
expected count. The subsequent WARN_ON() tells us that this has
happened, but we don't then have to base any further branching on this
condition (i != n_pages) as "addr" is already right. (Obviously, we
don't want to do the vmap() if we have exited the loop with the wrong
page count).
I'll post the other version, but I think the post-loop checking is
messier, to such an extent that this way round is simpler overall.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-20 9:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 17:40 [PATCH 1/2] drm/i915: refactor i915_gem_object_pin_map() Dave Gordon
2016-04-19 17:40 ` [PATCH 2/2] drm/i915: optimise i915_gem_object_map() for small objects Dave Gordon
2016-04-19 19:50 ` [PATCH 1/2] drm/i915: refactor i915_gem_object_pin_map() Chris Wilson
2016-04-20 9:39 ` Dave Gordon [this message]
2016-04-20 13:30 ` [PATCH v2 " Dave Gordon
2016-04-20 13:30 ` [PATCH v2 2/2] drm/i915: optimise i915_gem_object_map() for small objects Dave Gordon
2016-04-20 13:57 ` [PATCH v2 1/2] drm/i915: refactor i915_gem_object_pin_map() Dave Gordon
2016-04-21 8:09 ` Joonas Lahtinen
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=57174E58.7070701@intel.com \
--to=david.s.gordon@intel.com \
--cc=chris@chris-wilson.co.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox