| Message ID | 20200918163724.2511-5-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area | expand |
On 18/09/2020 17:37, Christoph Hellwig wrote: > i915_gem_object_map implements fairly low-level vmap functionality in > a driver. Split it into two helpers, one for remapping kernel memory > which can use vmap, and one for I/O memory that uses vmap_pfn. > > The only practical difference is that alloc_vm_area prefeaults the > vmalloc area PTEs, which doesn't seem to be required here for the > kernel memory case (and could be added to vmap using a flag if actually > required). Patch looks good to me. Series did not get a CI run from our side because of a different base so I don't know if you would like to have a run there? If so you would need to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could even send a series to intel-gfx-trybot@lists.freedesktop.org, suppressing cc, to check it out without sending a copy to the real mailing list. Regards, Tvrtko > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 101 ++++++++++------------ > 2 files changed, 47 insertions(+), 55 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 9afa5c4a6bf006..1e1cb245fca778 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -25,6 +25,7 @@ config DRM_I915 > select CRC32 > select SND_HDA_I915 if SND_HDA_CORE > select CEC_CORE if CEC_NOTIFIER > + select VMAP_PFN > help > Choose this option if you have a system that has "Intel Graphics > Media Accelerator" or "HD Graphics" integrated graphics, > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c > index e8a083743e0927..90029ea83aede9 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c > @@ -234,50 +234,24 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj) > return err; > } > > -static inline pte_t iomap_pte(resource_size_t base, > - dma_addr_t offset, > - pgprot_t prot) > -{ > - return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot)); > -} > - > /* The 'mapping' part of i915_gem_object_pin_map() below */ > -static void *i915_gem_object_map(struct drm_i915_gem_object *obj, > +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj, > enum i915_map_type type) > { > - unsigned long n_pte = obj->base.size >> PAGE_SHIFT; > - struct sg_table *sgt = obj->mm.pages; > - pte_t *stack[32], **mem; > - struct vm_struct *area; > + unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i; > + struct page *stack[32], **pages = stack, *page; > + struct sgt_iter iter; > pgprot_t pgprot; > - > - if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC) > - return NULL; > - > - /* A single page can always be kmapped */ > - if (n_pte == 1 && type == I915_MAP_WB) > - return kmap(sg_page(sgt->sgl)); > - > - mem = stack; > - if (n_pte > ARRAY_SIZE(stack)) { > - /* Too big for stack -- allocate temporary array instead */ > - mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL); > - if (!mem) > - return NULL; > - } > - > - area = alloc_vm_area(obj->base.size, mem); > - if (!area) { > - if (mem != stack) > - kvfree(mem); > - return NULL; > - } > + void *vaddr; > > switch (type) { > default: > MISSING_CASE(type); > fallthrough; /* to use PAGE_KERNEL anyway */ > case I915_MAP_WB: > + /* A single page can always be kmapped */ > + if (n_pages == 1) > + return kmap(sg_page(obj->mm.pages->sgl)); > pgprot = PAGE_KERNEL; > break; > case I915_MAP_WC: > @@ -285,30 +259,44 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, > break; > } > > - if (i915_gem_object_has_struct_page(obj)) { > - struct sgt_iter iter; > - struct page *page; > - pte_t **ptes = mem; > - > - for_each_sgt_page(page, iter, sgt) > - **ptes++ = mk_pte(page, pgprot); > - } else { > - resource_size_t iomap; > - struct sgt_iter iter; > - pte_t **ptes = mem; > - dma_addr_t addr; > + if (n_pages > ARRAY_SIZE(stack)) { > + /* Too big for stack -- allocate temporary array instead */ > + pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL); > + if (!pages) > + return NULL; > + } > > - iomap = obj->mm.region->iomap.base; > - iomap -= obj->mm.region->region.start; > + for_each_sgt_page(page, iter, obj->mm.pages) > + pages[i++] = page; > + vaddr = vmap(pages, n_pages, 0, pgprot); > + if (pages != stack) > + kvfree(pages); > + return vaddr; > +} > > - for_each_sgt_daddr(addr, iter, sgt) > - **ptes++ = iomap_pte(iomap, addr, pgprot); > +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj) > +{ > + resource_size_t iomap = obj->mm.region->iomap.base - > + obj->mm.region->region.start; > + unsigned long n_pfn = obj->base.size >> PAGE_SHIFT; > + unsigned long stack[32], *pfns = stack, i; > + struct sgt_iter iter; > + dma_addr_t addr; > + void *vaddr; > + > + if (n_pfn > ARRAY_SIZE(stack)) { > + /* Too big for stack -- allocate temporary array instead */ > + pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL); > + if (!pfns) > + return NULL; > } > > - if (mem != stack) > - kvfree(mem); > - > - return area->addr; > + for_each_sgt_daddr(addr, iter, obj->mm.pages) > + pfns[i++] = (iomap + addr) >> PAGE_SHIFT; > + vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO)); > + if (pfns != stack) > + kvfree(pfns); > + return vaddr; > } > > /* get, pin, and map the pages of the object into kernel space */ > @@ -360,7 +348,10 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, > } > > if (!ptr) { > - ptr = i915_gem_object_map(obj, type); > + if (i915_gem_object_has_struct_page(obj)) > + ptr = i915_gem_object_map_page(obj, type); > + else if (type == I915_MAP_WC) > + ptr = i915_gem_object_map_pfn(obj); > if (!ptr) { > err = -ENOMEM; > goto err_unpin; >
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: > > On 18/09/2020 17:37, Christoph Hellwig wrote: >> i915_gem_object_map implements fairly low-level vmap functionality in >> a driver. Split it into two helpers, one for remapping kernel memory >> which can use vmap, and one for I/O memory that uses vmap_pfn. >> >> The only practical difference is that alloc_vm_area prefeaults the >> vmalloc area PTEs, which doesn't seem to be required here for the >> kernel memory case (and could be added to vmap using a flag if actually >> required). > > Patch looks good to me. > > Series did not get a CI run from our side because of a different base so I > don't know if you would like to have a run there? If so you would need to > rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could > even send a series to intel-gfx-trybot@lists.freedesktop.org, suppressing > cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI.
On 23/09/2020 14:41, Christoph Hellwig wrote: > On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: >> >> On 18/09/2020 17:37, Christoph Hellwig wrote: >>> i915_gem_object_map implements fairly low-level vmap functionality in >>> a driver. Split it into two helpers, one for remapping kernel memory >>> which can use vmap, and one for I/O memory that uses vmap_pfn. >>> >>> The only practical difference is that alloc_vm_area prefeaults the >>> vmalloc area PTEs, which doesn't seem to be required here for the >>> kernel memory case (and could be added to vmap using a flag if actually >>> required). >> >> Patch looks good to me. >> >> Series did not get a CI run from our side because of a different base so I >> don't know if you would like to have a run there? If so you would need to >> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could >> even send a series to intel-gfx-trybot@lists.freedesktop.org, suppressing >> cc, to check it out without sending a copy to the real mailing list. > > It doesn't seem like I can post to any freedesktop list, as I always > get rejection messages. But I'll happily prepare a branch if one > of you an feed it into your CI. That's fine, just ping me and I will forward it for testing, thanks! Regards, Tvrtko
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: >>> Series did not get a CI run from our side because of a different base so I >>> don't know if you would like to have a run there? If so you would need to >>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could >>> even send a series to intel-gfx-trybot@lists.freedesktop.org, suppressing >>> cc, to check it out without sending a copy to the real mailing list. >> >> It doesn't seem like I can post to any freedesktop list, as I always >> get rejection messages. But I'll happily prepare a branch if one >> of you an feed it into your CI. > > That's fine, just ping me and I will forward it for testing, thanks! git://git.infradead.org/users/hch/misc.git i915-vmap-wip Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip note that this includes a new commit to clean up one of the recent commits in the code.
On 23/09/2020 15:44, Christoph Hellwig wrote: > On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: >>>> Series did not get a CI run from our side because of a different base so I >>>> don't know if you would like to have a run there? If so you would need to >>>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could >>>> even send a series to intel-gfx-trybot@lists.freedesktop.org, suppressing >>>> cc, to check it out without sending a copy to the real mailing list. >>> >>> It doesn't seem like I can post to any freedesktop list, as I always >>> get rejection messages. But I'll happily prepare a branch if one >>> of you an feed it into your CI. >> >> That's fine, just ping me and I will forward it for testing, thanks! > > git://git.infradead.org/users/hch/misc.git i915-vmap-wip > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip > > note that this includes a new commit to clean up one of the recent > commits in the code. CI says series looks good from the i915 perspective (*). I don't know how will you handle it logistically, but when you have final version I am happy to re-read and r-b the i915 patches. Regards, Tvrtko *) https://patchwork.freedesktop.org/series/82051/
On Thu, Sep 24, 2020 at 01:22:35PM +0100, Tvrtko Ursulin wrote: > CI says series looks good from the i915 perspective (*). > > I don't know how will you handle it logistically, but when you have final > version I am happy to re-read and r-b the i915 patches. I'll resend the series later today, and will make sure you are on the Cc list.
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 9afa5c4a6bf006..1e1cb245fca778 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -25,6 +25,7 @@ config DRM_I915 select CRC32 select SND_HDA_I915 if SND_HDA_CORE select CEC_CORE if CEC_NOTIFIER + select VMAP_PFN help Choose this option if you have a system that has "Intel Graphics Media Accelerator" or "HD Graphics" integrated graphics, diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index e8a083743e0927..90029ea83aede9 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -234,50 +234,24 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj) return err; } -static inline pte_t iomap_pte(resource_size_t base, - dma_addr_t offset, - pgprot_t prot) -{ - return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot)); -} - /* The 'mapping' part of i915_gem_object_pin_map() below */ -static void *i915_gem_object_map(struct drm_i915_gem_object *obj, +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj, enum i915_map_type type) { - unsigned long n_pte = obj->base.size >> PAGE_SHIFT; - struct sg_table *sgt = obj->mm.pages; - pte_t *stack[32], **mem; - struct vm_struct *area; + unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i; + struct page *stack[32], **pages = stack, *page; + struct sgt_iter iter; pgprot_t pgprot; - - if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC) - return NULL; - - /* A single page can always be kmapped */ - if (n_pte == 1 && type == I915_MAP_WB) - return kmap(sg_page(sgt->sgl)); - - mem = stack; - if (n_pte > ARRAY_SIZE(stack)) { - /* Too big for stack -- allocate temporary array instead */ - mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL); - if (!mem) - return NULL; - } - - area = alloc_vm_area(obj->base.size, mem); - if (!area) { - if (mem != stack) - kvfree(mem); - return NULL; - } + void *vaddr; switch (type) { default: MISSING_CASE(type); fallthrough; /* to use PAGE_KERNEL anyway */ case I915_MAP_WB: + /* A single page can always be kmapped */ + if (n_pages == 1) + return kmap(sg_page(obj->mm.pages->sgl)); pgprot = PAGE_KERNEL; break; case I915_MAP_WC: @@ -285,30 +259,44 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, break; } - if (i915_gem_object_has_struct_page(obj)) { - struct sgt_iter iter; - struct page *page; - pte_t **ptes = mem; - - for_each_sgt_page(page, iter, sgt) - **ptes++ = mk_pte(page, pgprot); - } else { - resource_size_t iomap; - struct sgt_iter iter; - pte_t **ptes = mem; - dma_addr_t addr; + if (n_pages > ARRAY_SIZE(stack)) { + /* Too big for stack -- allocate temporary array instead */ + pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL); + if (!pages) + return NULL; + } - iomap = obj->mm.region->iomap.base; - iomap -= obj->mm.region->region.start; + for_each_sgt_page(page, iter, obj->mm.pages) + pages[i++] = page; + vaddr = vmap(pages, n_pages, 0, pgprot); + if (pages != stack) + kvfree(pages); + return vaddr; +} - for_each_sgt_daddr(addr, iter, sgt) - **ptes++ = iomap_pte(iomap, addr, pgprot); +static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj) +{ + resource_size_t iomap = obj->mm.region->iomap.base - + obj->mm.region->region.start; + unsigned long n_pfn = obj->base.size >> PAGE_SHIFT; + unsigned long stack[32], *pfns = stack, i; + struct sgt_iter iter; + dma_addr_t addr; + void *vaddr; + + if (n_pfn > ARRAY_SIZE(stack)) { + /* Too big for stack -- allocate temporary array instead */ + pfns = kvmalloc_array(n_pfn, sizeof(*pfns), GFP_KERNEL); + if (!pfns) + return NULL; } - if (mem != stack) - kvfree(mem); - - return area->addr; + for_each_sgt_daddr(addr, iter, obj->mm.pages) + pfns[i++] = (iomap + addr) >> PAGE_SHIFT; + vaddr = vmap_pfn(pfns, n_pfn, pgprot_writecombine(PAGE_KERNEL_IO)); + if (pfns != stack) + kvfree(pfns); + return vaddr; } /* get, pin, and map the pages of the object into kernel space */ @@ -360,7 +348,10 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, } if (!ptr) { - ptr = i915_gem_object_map(obj, type); + if (i915_gem_object_has_struct_page(obj)) + ptr = i915_gem_object_map_page(obj, type); + else if (type == I915_MAP_WC) + ptr = i915_gem_object_map_pfn(obj); if (!ptr) { err = -ENOMEM; goto err_unpin;
i915_gem_object_map implements fairly low-level vmap functionality in a driver. Split it into two helpers, one for remapping kernel memory which can use vmap, and one for I/O memory that uses vmap_pfn. The only practical difference is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't seem to be required here for the kernel memory case (and could be added to vmap using a flag if actually required). Signed-off-by: Christoph Hellwig <hch@lst.de> --- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/gem/i915_gem_pages.c | 101 ++++++++++------------ 2 files changed, 47 insertions(+), 55 deletions(-)