From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Tvrtko Ursulin <tursulin@ursulin.net>,
Intel-gfx@lists.freedesktop.org,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH 0/4] Compact userptr object backing store allocation
Date: Mon, 28 Nov 2016 10:23:49 +0000 [thread overview]
Message-ID: <919b5b47-5634-d144-3643-d0c97972aaa7@linux.intel.com> (raw)
In-Reply-To: <1676c507-37b4-6bfa-8158-2e373db7e7cc@linux.intel.com>
On 14/11/2016 11:45, Tvrtko Ursulin wrote:
>
> Hi Andrew,
>
> On 11/11/2016 08:50, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Userptr backing store with SWIOTBL active is currently allocated in
>> the same
>> inefficient manner, with one sg entry per object page, as what the commit
>> 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment
>> size") fixed
>> for regular GEM objects.
>>
>> We can fix that by adding new a __sg_alloc_table_from_pages core
>> function which
>> allows us to control the maximum desired coalesced segment size.
>>
>> Other than that the series starts with two simple fixes to
>> sg_alloc_table_from_pages which deal with incorrect data type usage and a
>> theoretical overflow condition. Fixing the latter enables easy
>> addition of the
>> above mentioned __sg_alloc_table_from_pages.
>>
>> Tvrtko Ursulin (4):
>> lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
>> lib/scatterlist: Avoid potential scatterlist entry overflow
>> lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
>> drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
>>
>> drivers/gpu/drm/i915/i915_drv.h | 9 +++
>> drivers/gpu/drm/i915/i915_gem.c | 15 +----
>> drivers/gpu/drm/i915/i915_gem_userptr.c | 28 ++-------
>> drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 +-
>> drivers/rapidio/devices/rio_mport_cdev.c | 4 +-
>> include/linux/scatterlist.h | 11 ++--
>> lib/scatterlist.c | 78
>> ++++++++++++++++++++------
>> 7 files changed, 87 insertions(+), 62 deletions(-)
>
> I have three patches to lib/scatterlist.c in this series which has all
> been reviewed and tested.
>
> We would like to merge them via the DRM tree if there are no objections?
Excuse me for the re-ping - still looking for an ack to merge these few
patches via the drm tree. (The code in question does not have a
designated maintainer.)
Regards,
Tvrtko
prev parent reply other threads:[~2016-11-28 10:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 8:50 [PATCH 0/4] Compact userptr object backing store allocation Tvrtko Ursulin
2016-11-11 8:50 ` [PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages Tvrtko Ursulin
2016-11-14 9:55 ` [Intel-gfx] " Chris Wilson
2016-11-22 14:31 ` Mauro Carvalho Chehab
2016-11-11 8:50 ` [PATCH 2/4] lib/scatterlist: Avoid potential scatterlist entry overflow Tvrtko Ursulin
2016-11-11 10:19 ` [Intel-gfx] " Chris Wilson
2016-11-11 8:50 ` [PATCH 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages Tvrtko Ursulin
2016-11-11 10:24 ` [Intel-gfx] " Chris Wilson
2016-11-11 12:35 ` [PATCH v2 " Tvrtko Ursulin
2016-11-11 14:17 ` [PATCH v3 " Tvrtko Ursulin
2016-11-14 9:51 ` Chris Wilson
2016-11-11 8:50 ` [PATCH 4/4] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations Tvrtko Ursulin
2016-11-11 8:59 ` [PATCH v3 " Tvrtko Ursulin
2016-11-11 10:23 ` [PATCH " Chris Wilson
2016-11-11 12:36 ` [PATCH v4 " Tvrtko Ursulin
2016-11-14 9:52 ` Chris Wilson
2016-11-14 11:45 ` [Intel-gfx] [PATCH 0/4] Compact userptr object backing store allocation Tvrtko Ursulin
2016-11-28 10:23 ` Tvrtko Ursulin [this message]
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=919b5b47-5634-d144-3643-d0c97972aaa7@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=tursulin@ursulin.net \
/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;
as well as URLs for NNTP newsgroup(s).