From: Zhao Liu <[email protected]>
The use of kmap_atomic() is being deprecated in favor of
kmap_local_page()[1].
The main difference between atomic and local mappings is that local
mappings doesn't disable page faults or preemption.
In drm/i915/gem/i915_gem_phys.c, the functions
i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
don't need to disable pagefaults and preemption for mapping because of
these 2 reasons:
1. The flush operation is safe for CPU hotplug when preemption is not
disabled. In drm/i915/gem/i915_gem_object.c, the functions
i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
calls drm_clflush_virt_range() to use CLFLUSHOPT or WBINVD to flush.
Since CLFLUSHOPT is global on x86 and WBINVD is called on each cpu in
drm_clflush_virt_range(), the flush operation is global and any issue
with cpu's being added or removed can be handled safely.
2. Any context switch caused by preemption or sleep (pagefault may
cause sleep) doesn't affect the validity of local mapping.
Therefore, i915_gem_object_get_pages_phys() and
i915_gem_object_put_pages_phys() are two functions where the use of
kmap_local_page() in place of kmap_atomic() is correctly suited.
Convert the calls of kmap_atomic() / kunmap_atomic() to
kmap_local_page() / kunmap_local().
[1]: https://lore.kernel.org/all/[email protected]
Suggested-by: Dave Hansen <[email protected]>
Suggested-by: Ira Weiny <[email protected]>
Suggested-by: Fabio M. De Francesco <[email protected]>
Signed-off-by: Zhao Liu <[email protected]>
---
Suggested by credits:
Dave: Referred to his explanation about cache flush.
Ira: Referred to his task document, review comments and explanation about
cache flush.
Fabio: Referred to his boiler plate commit message.
---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 0d0e46dae559..d602ba19ecb2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -66,10 +66,10 @@ static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
if (IS_ERR(page))
goto err_st;
- src = kmap_atomic(page);
+ src = kmap_local_page(page);
memcpy(dst, src, PAGE_SIZE);
drm_clflush_virt_range(dst, PAGE_SIZE);
- kunmap_atomic(src);
+ kunmap_local(src);
put_page(page);
dst += PAGE_SIZE;
@@ -114,10 +114,10 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
if (IS_ERR(page))
continue;
- dst = kmap_atomic(page);
+ dst = kmap_local_page(page);
drm_clflush_virt_range(src, PAGE_SIZE);
memcpy(dst, src, PAGE_SIZE);
- kunmap_atomic(dst);
+ kunmap_local(dst);
set_page_dirty(page);
if (obj->mm.madv == I915_MADV_WILLNEED)
--
2.34.1
On luned? 17 ottobre 2022 11:37:18 CEST Zhao Liu wrote:
> From: Zhao Liu <[email protected]>
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
>
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
>
> In drm/i915/gem/i915_gem_phys.c, the functions
> i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
> don't need to disable pagefaults and preemption for mapping because of
> these 2 reasons:
>
> 1. The flush operation is safe for CPU hotplug when preemption is not
> disabled. In drm/i915/gem/i915_gem_object.c, the functions
> i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
> calls drm_clflush_virt_range() to use CLFLUSHOPT or WBINVD to flush.
> Since CLFLUSHOPT is global on x86 and WBINVD is called on each cpu in
> drm_clflush_virt_range(), the flush operation is global and any issue
> with cpu's being added or removed can be handled safely.
>
> 2. Any context switch caused by preemption or sleep (pagefault may
> cause sleep) doesn't affect the validity of local mapping.
>
> Therefore, i915_gem_object_get_pages_phys() and
> i915_gem_object_put_pages_phys() are two functions where the use of
> kmap_local_page() in place of kmap_atomic() is correctly suited.
>
> Convert the calls of kmap_atomic() / kunmap_atomic() to
> kmap_local_page() / kunmap_local().
>
I have here the same questions as in 1/9.
> [1]: https://lore.kernel.org/all/[email protected]
>
> Suggested-by: Dave Hansen <[email protected]>
> Suggested-by: Ira Weiny <[email protected]>
> Suggested-by: Fabio M. De Francesco <[email protected]>
> Signed-off-by: Zhao Liu <[email protected]>
> ---
> Suggested by credits:
> Dave: Referred to his explanation about cache flush.
> Ira: Referred to his task document, review comments and explanation about
> cache flush.
> Fabio: Referred to his boiler plate commit message.
> ---
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> b/drivers/gpu/drm/i915/gem/i915_gem_phys.c index 0d0e46dae559..d602ba19ecb2
100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> @@ -66,10 +66,10 @@ static int i915_gem_object_get_pages_phys(struct
drm_i915_gem_object
> *obj) if (IS_ERR(page))
> goto err_st;
>
> - src = kmap_atomic(page);
> + src = kmap_local_page(page);
> memcpy(dst, src, PAGE_SIZE);
> drm_clflush_virt_range(dst, PAGE_SIZE);
> - kunmap_atomic(src);
> + kunmap_local(src);
Please use memcpy_from_page() instead of open coding mapping + memcpy() +
unmapping.
>
> put_page(page);
> dst += PAGE_SIZE;
> @@ -114,10 +114,10 @@ i915_gem_object_put_pages_phys(struct
drm_i915_gem_object *obj,
> if (IS_ERR(page))
> continue;
>
> - dst = kmap_atomic(page);
> + dst = kmap_local_page(page);
> drm_clflush_virt_range(src, PAGE_SIZE);
> memcpy(dst, src, PAGE_SIZE);
> - kunmap_atomic(dst);
> + kunmap_local(dst);
For the same reasons said above, memcpy_to_page() should be used here and
avoid open coding of three functions.
Using those helpers forces you to move drm_clflush_virt_range() out of the
mapping / un-mapping region. I may be wrong, however I'm pretty sure that the
relative positions of each of those call sites is something that cannot be
randomly chosen.
Thanks,
Fabio
>
> set_page_dirty(page);
> if (obj->mm.madv == I915_MADV_WILLNEED)
On Sat, Oct 29, 2022 at 03:32:08PM +0200, Fabio M. De Francesco wrote:
> Date: Sat, 29 Oct 2022 15:32:08 +0200
> From: "Fabio M. De Francesco" <[email protected]>
> Subject: Re: [PATCH 2/9] drm/i915: Use kmap_local_page() in
> gem/i915_gem_pyhs.c
>
> On luned? 17 ottobre 2022 11:37:18 CEST Zhao Liu wrote:
> > From: Zhao Liu <[email protected]>
> >
> > The use of kmap_atomic() is being deprecated in favor of
> > kmap_local_page()[1].
> >
> > The main difference between atomic and local mappings is that local
> > mappings doesn't disable page faults or preemption.
> >
> > In drm/i915/gem/i915_gem_phys.c, the functions
> > i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
> > don't need to disable pagefaults and preemption for mapping because of
> > these 2 reasons:
> >
> > 1. The flush operation is safe for CPU hotplug when preemption is not
> > disabled. In drm/i915/gem/i915_gem_object.c, the functions
> > i915_gem_object_get_pages_phys() and i915_gem_object_put_pages_phys()
> > calls drm_clflush_virt_range() to use CLFLUSHOPT or WBINVD to flush.
> > Since CLFLUSHOPT is global on x86 and WBINVD is called on each cpu in
> > drm_clflush_virt_range(), the flush operation is global and any issue
> > with cpu's being added or removed can be handled safely.
> >
> > 2. Any context switch caused by preemption or sleep (pagefault may
> > cause sleep) doesn't affect the validity of local mapping.
> >
> > Therefore, i915_gem_object_get_pages_phys() and
> > i915_gem_object_put_pages_phys() are two functions where the use of
> > kmap_local_page() in place of kmap_atomic() is correctly suited.
> >
> > Convert the calls of kmap_atomic() / kunmap_atomic() to
> > kmap_local_page() / kunmap_local().
> >
>
> I have here the same questions as in 1/9.
>
> > [1]: https://lore.kernel.org/all/[email protected]
> >
> > Suggested-by: Dave Hansen <[email protected]>
> > Suggested-by: Ira Weiny <[email protected]>
> > Suggested-by: Fabio M. De Francesco <[email protected]>
> > Signed-off-by: Zhao Liu <[email protected]>
> > ---
> > Suggested by credits:
> > Dave: Referred to his explanation about cache flush.
> > Ira: Referred to his task document, review comments and explanation about
> > cache flush.
> > Fabio: Referred to his boiler plate commit message.
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_phys.c index 0d0e46dae559..d602ba19ecb2
> 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
> > @@ -66,10 +66,10 @@ static int i915_gem_object_get_pages_phys(struct
> drm_i915_gem_object
> > *obj) if (IS_ERR(page))
> > goto err_st;
> >
> > - src = kmap_atomic(page);
> > + src = kmap_local_page(page);
> > memcpy(dst, src, PAGE_SIZE);
> > drm_clflush_virt_range(dst, PAGE_SIZE);
> > - kunmap_atomic(src);
> > + kunmap_local(src);
>
> Please use memcpy_from_page() instead of open coding mapping + memcpy() +
> unmapping.
Ok.
>
> >
> > put_page(page);
> > dst += PAGE_SIZE;
> > @@ -114,10 +114,10 @@ i915_gem_object_put_pages_phys(struct
> drm_i915_gem_object *obj,
> > if (IS_ERR(page))
> > continue;
> >
> > - dst = kmap_atomic(page);
> > + dst = kmap_local_page(page);
> > drm_clflush_virt_range(src, PAGE_SIZE);
> > memcpy(dst, src, PAGE_SIZE);
> > - kunmap_atomic(dst);
> > + kunmap_local(dst);
>
> For the same reasons said above, memcpy_to_page() should be used here and
> avoid open coding of three functions.
>
> Using those helpers forces you to move drm_clflush_virt_range() out of the
> mapping / un-mapping region. I may be wrong, however I'm pretty sure that the
> relative positions of each of those call sites is something that cannot be
> randomly chosen.
I agree. Will use memcpy_to_page().
Thanks,
Zhao
>
> Thanks,
>
> Fabio
>
> >
> > set_page_dirty(page);
> > if (obj->mm.madv == I915_MADV_WILLNEED)
>
>
>