Re: [PATCH 05/22] drm/i915: introduce page_size members

Chris Wilson
2017-08-15T18:37:52Z

Quoting Matthew Auld (2017-08-15 19:11:58)
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index f152a38d7079..6861ebd1323b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -406,7 +406,8 @@ struct get_pages_work {
> #endif
>
> static int
> -st_set_pages(struct sg_table **st, struct page **pvec, int num_pages)
> +st_set_pages(struct sg_table **st, struct page **pvec, int num_pages,
> + unsigned int *sg_mask)
> {
> struct scatterlist *sg;
> int ret, n;
> @@ -422,12 +423,17 @@ st_set_pages(struct sg_table **st, struct page **pvec, int num_pages)
>
> for_each_sg((*st)->sgl, sg, num_pages, n)
> sg_set_page(sg, pvec[n], PAGE_SIZE, 0);
> +
> + *sg_mask = PAGE_SIZE;
> } else {
> ret = sg_alloc_table_from_pages(*st, pvec, num_pages,
> 0, num_pages << PAGE_SHIFT,
> GFP_KERNEL);
> if (ret)
> goto err;
> +
> + for_each_sg((*st)->sgl, sg, num_pages, n)
> + *sg_mask |= sg->length;

Hmm. userptr may be shortlived, i.e. see more than their fair share of
get_pages. Need to keep an eye on this to see if this additional walk
shows up - the latency will most likely be on the execbuf submission path.

One way around that would be a flag to do the getpages at creation time,
though the reason it was deferred was that many userptrs were being made
that never were used for execbuf (backing SHM images).

But this reminds me we need to land Tvrtko's work so that we can handle
superpages here.
-Chris