[Intel-gfx] [PATCH v2 4/9] drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c
Ira Weiny
ira.weiny at intel.com
Fri Mar 31 03:04:39 UTC 2023
Zhao Liu wrote:
> From: Zhao Liu <zhao1.liu at intel.com>
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1], and this patch converts the call from
> kmap_atomic() to kmap_local_page().
>
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption (the preemption is
> disabled for !PREEMPT_RT case, otherwise it only disables migration).
>
> With kmap_local_page(), we can avoid the often unwanted side effect of
> unnecessary page faults or preemption disables.
>
> In drm/i915/gem/selftests/huge_pages.c, function __cpu_check_shmem()
> mainly uses mapping to flush cache and check the value. There're
> 2 reasons why __cpu_check_shmem() doesn't need to disable pagefaults
> and preemption for mapping:
>
> 1. The flush operation is safe. Function __cpu_check_shmem() 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.
>
> 2. Any context switch caused by preemption or page faults (page fault
> may cause sleep) doesn't affect the validity of local mapping.
>
> Therefore, __cpu_check_shmem() is a function 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/20220813220034.806698-1-ira.weiny@intel.com
>
> v2:
> * Dropped hot plug related description since it has nothing to do with
> kmap_local_page().
> * No code change since v1, and added description of the motivation of
> using kmap_local_page().
>
> Suggested-by: Dave Hansen <dave.hansen at intel.com>
> Suggested-by: Ira Weiny <ira.weiny at intel.com>
Reviewed-by: Ira Weiny <ira.weiny at intel.com>
More information about the Intel-gfx
mailing list