| Message ID | 20221013210714.16320-1-fmdefrancesco@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | drm/radeon: Replace kmap() with kmap_local_page() | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
On Thu, Oct 13, 2022 at 11:07:14PM +0200, Fabio M. De Francesco wrote: > The use of kmap() is being deprecated in favor of kmap_local_page(). > > There are two main problems with kmap(): (1) It comes with an overhead as > the mapping space is restricted and protected by a global lock for > synchronization and (2) it also requires global TLB invalidation when the > kmap’s pool wraps and it might block when the mapping space is fully > utilized until a slot becomes available. > > With kmap_local_page() the mappings are per thread, CPU local, can take > page faults, and can be called from any context (including interrupts). > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > the tasks can be preempted and, when they are scheduled to run again, the > kernel virtual addresses are restored and still valid. > > Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read(). > > Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com> > Suggested-by: Ira Weiny <ira.weiny@intel.com> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org>
Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco: > The use of kmap() is being deprecated in favor of kmap_local_page(). > > There are two main problems with kmap(): (1) It comes with an overhead as > the mapping space is restricted and protected by a global lock for > synchronization and (2) it also requires global TLB invalidation when the > kmap’s pool wraps and it might block when the mapping space is fully > utilized until a slot becomes available. > > With kmap_local_page() the mappings are per thread, CPU local, can take > page faults, and can be called from any context (including interrupts). > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > the tasks can be preempted and, when they are scheduled to run again, the > kernel virtual addresses are restored and still valid. > > Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read(). > > Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com> > Suggested-by: Ira Weiny <ira.weiny@intel.com> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> > --- > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c > index d33fec488713..bdb4c0e0736b 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf, > > page = rdev->gart.pages[p]; > if (page) { > - ptr = kmap(page); > + ptr = kmap_local_page(page); > ptr += off; > > r = copy_to_user(buf, ptr, cur_size); > - kunmap(rdev->gart.pages[p]); > + kunmap_local(ptr); > } else > r = clear_user(buf, cur_size); >
Applied. Thanks! On Fri, Oct 14, 2022 at 3:03 AM Christian König <christian.koenig@amd.com> wrote: > > Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco: > > The use of kmap() is being deprecated in favor of kmap_local_page(). > > > > There are two main problems with kmap(): (1) It comes with an overhead as > > the mapping space is restricted and protected by a global lock for > > synchronization and (2) it also requires global TLB invalidation when the > > kmap’s pool wraps and it might block when the mapping space is fully > > utilized until a slot becomes available. > > > > With kmap_local_page() the mappings are per thread, CPU local, can take > > page faults, and can be called from any context (including interrupts). > > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > > the tasks can be preempted and, when they are scheduled to run again, the > > kernel virtual addresses are restored and still valid. > > > > Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read(). > > > > Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com> > > Suggested-by: Ira Weiny <ira.weiny@intel.com> > > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> > > Reviewed-by: Christian König <christian.koenig@amd.com> > > > --- > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c > > index d33fec488713..bdb4c0e0736b 100644 > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > > @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf, > > > > page = rdev->gart.pages[p]; > > if (page) { > > - ptr = kmap(page); > > + ptr = kmap_local_page(page); > > ptr += off; > > > > r = copy_to_user(buf, ptr, cur_size); > > - kunmap(rdev->gart.pages[p]); > > + kunmap_local(ptr); > > } else > > r = clear_user(buf, cur_size); > > >
On lunedì 17 ottobre 2022 18:52:10 CET Alex Deucher wrote:
> Applied. Thanks!
Many thanks to you!
However, about a week ago, I received a report saying that this patch is "Not
Applicable".
That email was also referring to another patch, for which I'll reply in its
own thread.
That report has a link to https://patchwork.linuxtv.org/project/linux-media/
patch/20221013210714.16320-1-fmdefrancesco@gmail.com/
Can you please let me understand why, despite it was applied, this patch later
shifted "State" to "Not Applicable"?
Thanks,
Fabio
On Wed, Nov 02, 2022 at 12:11:53AM +0100, Fabio M. De Francesco wrote: > On lunedì 17 ottobre 2022 18:52:10 CET Alex Deucher wrote: > > Applied. Thanks! > > Many thanks to you! > > However, about a week ago, I received a report saying that this patch is "Not > Applicable". > > That email was also referring to another patch, for which I'll reply in its > own thread. > > That report has a link to https://patchwork.linuxtv.org/project/linux-media/ > patch/20221013210714.16320-1-fmdefrancesco@gmail.com/ > > Can you please let me understand why, despite it was applied, this patch later > shifted "State" to "Not Applicable"? The kernel has multiple patchwork instances, so you got an "N/A" from linux-media, but it was applied to the drm tree. (Yes, confusing. :P)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index d33fec488713..bdb4c0e0736b 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf, page = rdev->gart.pages[p]; if (page) { - ptr = kmap(page); + ptr = kmap_local_page(page); ptr += off; r = copy_to_user(buf, ptr, cur_size); - kunmap(rdev->gart.pages[p]); + kunmap_local(ptr); } else r = clear_user(buf, cur_size);
The use of kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read(). Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com> Suggested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)