From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E534C74A5B for ; Wed, 29 Mar 2023 07:24:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230019AbjC2HYr (ORCPT ); Wed, 29 Mar 2023 03:24:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229951AbjC2HYV (ORCPT ); Wed, 29 Mar 2023 03:24:21 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06D1040C5 for ; Wed, 29 Mar 2023 00:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074659; x=1711610659; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LRvnQ75nV6J4t1eJkOClYlFPCaO/BWveDjZ+1rUjKAM=; b=dizsUuUIdk4ylU60Y+d0K2/e2AY6pSPkIADjgXARvM7hieN87aWl77WN S1zUX/917/P4ZHOBlvT7manw40Ua7pEk3MOGsP0n1HvOZ3d63fxoK0Rqc P82p32nBYMSxnesPbMSX2LQO9hN8pO3p1dSqU3M9Ray0ejTee7Kwb0J6w C1ddR1af+Pz2SmyAsuIi/6rOYEZsEdZLyujZ5Nfk3/J6lg7CkPpheko8D VIYyXub1W48vwBm7Q+kJwajfcM9TL6ffcMphTZLW1StPHZCgm3kSCupSS cRUQNT820hmpbKOIBMjrc1yJVp8pdDyFptazoEKOYgjHHblTwMDDi8r5l g==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405745851" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405745851" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160545" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160545" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:14 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 1/9] drm/i915: Use kmap_local_page() in gem/i915_gem_object.c Date: Wed, 29 Mar 2023 15:32:12 +0800 Message-Id: <20230329073220.3982460-2-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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 and preemption disables. There're 2 reasons why i915_gem_object_read_from_page_kmap() doesn't need to disable pagefaults and preemption for mapping: 1. The flush operation is safe. In drm/i915/gem/i915_gem_object.c, i915_gem_object_read_from_page_kmap() 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, i915_gem_object_read_from_page_kmap() 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(). And remove the redundant variable that stores the address of the mapped page since kunmap_local() can accept any pointer within the page. [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(). * Rebased on f47e630 (drm/i915/gem: Typecheck page lookups) to keep the "idx" variable of type pgoff_t here. * Added description of the motivation of using kmap_local_page(). Suggested-by: Dave Hansen Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i= 915/gem/i915_gem_object.c index e6d4efde4fc5..c0bfdd7784f7 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -428,17 +428,15 @@ static void i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64 o= ffset, void *dst, int size) { pgoff_t idx =3D offset >> PAGE_SHIFT; - void *src_map; void *src_ptr; =20 - src_map =3D kmap_atomic(i915_gem_object_get_page(obj, idx)); - - src_ptr =3D src_map + offset_in_page(offset); + src_ptr =3D kmap_local_page(i915_gem_object_get_page(obj, idx)) + + offset_in_page(offset); if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ)) drm_clflush_virt_range(src_ptr, size); memcpy(dst, src_ptr, size); =20 - kunmap_atomic(src_map); + kunmap_local(src_ptr); } =20 static void --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B448EC6FD18 for ; Wed, 29 Mar 2023 07:24:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229985AbjC2HY6 (ORCPT ); Wed, 29 Mar 2023 03:24:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229728AbjC2HY0 (ORCPT ); Wed, 29 Mar 2023 03:24:26 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 804AE2107 for ; Wed, 29 Mar 2023 00:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074665; x=1711610665; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B9E1ILllxkVCqOIIL0NVEqX87fQCrIe+LT/GYjLQv6c=; b=IPGrewcs7t+1gJaCxxOmOAXIwBwe3Lftr+sTZUC9jjydLOky2hYLj9Tj q8qmDCFtqMtQ4qA5Bwh/erUuPNfrtOR0tSOutstkukzP8N726bNjVVmTM jTZ76J2kujy9/sWp49JChKoRKg/imsYjtnUT25skJoncj84JZ+u9Ppn5q yB7ZXVdqrdYsY7j3NNyuqdt9+bA8b+MVxGMRX5F1LocBgVM54da9DnCc9 xcz0ZkRrFscRg8KM2jm+0Sc7EfG5QtS+7o3k7x/DhhopgCY6mHd68gNho AtTDrHgPq1g3xyttioTLAM7K24b43Ma3f6VHrx6jX1q9LXVN9xWVNOshP g==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405745878" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405745878" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160553" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160553" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:19 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 2/9] drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c Date: Wed, 29 Mar 2023 15:32:13 +0800 Message-Id: <20230329073220.3982460-3-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu The use of kmap_atomic() is being deprecated in favor of kmap_local_page()[1], and this patch converts the call from kmap_atomic() + memcpy() to memcpy_[from/to]_page(), which use kmap_local_page() to build local mapping and then do memcpy(). 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 and preemption disables. 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 2 reasons: 1. The flush operation is safe. In drm/i915/gem/i915_gem_object.c, 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. 2. Any context switch caused by preemption or page faults (page fault 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 uses of local mappings in place of atomic mappings are correctly suited. Convert the calls of kmap_atomic() / kunmap_atomic() + memcpy() to memcpy_from_page() and memcpy_to_page(). [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com v2: * Used memcpy_from_page() and memcpy_to_page() to replace kmap_local_page() + memcpy(). * Dropped hot plug related description since it has nothing to do with kmap_local_page(). * Added description of the motivation of using kmap_local_page(). Suggested-by: Dave Hansen Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. Also based on his suggestion to use memcpy_[from/to]_page() directly. --- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c b/drivers/gpu/drm/i91= 5/gem/i915_gem_phys.c index 76efe98eaa14..4c6d3f07260a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c @@ -64,16 +64,13 @@ static int i915_gem_object_get_pages_phys(struct drm_i9= 15_gem_object *obj) dst =3D vaddr; for (i =3D 0; i < obj->base.size / PAGE_SIZE; i++) { struct page *page; - void *src; =20 page =3D shmem_read_mapping_page(mapping, i); if (IS_ERR(page)) goto err_st; =20 - src =3D kmap_atomic(page); - memcpy(dst, src, PAGE_SIZE); + memcpy_from_page(dst, page, 0, PAGE_SIZE); drm_clflush_virt_range(dst, PAGE_SIZE); - kunmap_atomic(src); =20 put_page(page); dst +=3D PAGE_SIZE; @@ -112,16 +109,13 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_ob= ject *obj, =20 for (i =3D 0; i < obj->base.size / PAGE_SIZE; i++) { struct page *page; - char *dst; =20 page =3D shmem_read_mapping_page(mapping, i); if (IS_ERR(page)) continue; =20 - dst =3D kmap_atomic(page); drm_clflush_virt_range(src, PAGE_SIZE); - memcpy(dst, src, PAGE_SIZE); - kunmap_atomic(dst); + memcpy_to_page(page, 0, src, PAGE_SIZE); =20 set_page_dirty(page); if (obj->mm.madv =3D=3D I915_MADV_WILLNEED) --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 734F6C6FD18 for ; Wed, 29 Mar 2023 07:25:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230002AbjC2HZA (ORCPT ); Wed, 29 Mar 2023 03:25:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbjC2HYa (ORCPT ); Wed, 29 Mar 2023 03:24:30 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFCDB213A for ; Wed, 29 Mar 2023 00:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074669; x=1711610669; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lZB7D+9oAqqUk803oQiOFCr0X6utrKVFTvfta1a/CQQ=; b=G2hggRGu5eXem7cemsyrXbUwebGh8sXC4ws42/S8YubBv+V++lBn5mt/ 7wjuSClFs/Up0rK+EdCXfQbNYHpcXDMXxlGdhJW3h2SwDIPIp+XKycs5L y+pat0/YK9ObD7X8MxbmquTOeznO0fqGaAbrFILARQqmMz4HSclPrGfCR py+N+bExBAvEPeuLMOtkx56FTiGfO9LhczUXuu/9IIYUpb5Eq0qkrPkT+ 68vu6DCFOSRpH/0gMAdREgf4ngRB0d/U9gUH1G36dRKR2S3MkbNPA/kAE eBU6EEB2tyJIj5tY1mGpmB+rIP51lNJfp3P0PiXrGYKiw4nr9RLYB3eqK g==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405745889" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405745889" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160559" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160559" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:24 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu Subject: [PATCH v2 3/9] drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c Date: Wed, 29 Mar 2023 15:32:14 +0800 Message-Id: <20230329073220.3982460-4-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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 (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/i915_gem_shmem.c, the function shmem_pwrite() need to disable pagefault to eliminate the potential recursion fault[2]. But here __copy_from_user_inatomic() doesn't need to disable preemption and local mapping is valid for sched in/out. So it can use kmap_local_page() / kunmap_local() with pagefault_disable() / pagefault_enable() to replace atomic mapping. [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com [2]: https://patchwork.freedesktop.org/patch/295840/ v2: No code change since v1, and added description of the motivation of using kmap_local_page(). Suggested-by: Ira Weiny Reviewed-by: Ira Weiny Reviewed-by: Fabio M. De Francesco Signed-off-by: Zhao Liu --- Suggested by credits: Ira: Referred to his suggestions about keeping pagefault_disable(). Fabio: Referred to his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i9= 15/gem/i915_gem_shmem.c index 37d1efcd3ca6..ad69a79c8b31 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -475,11 +475,13 @@ shmem_pwrite(struct drm_i915_gem_object *obj, if (err < 0) return err; =20 - vaddr =3D kmap_atomic(page); + vaddr =3D kmap_local_page(page); + pagefault_disable(); unwritten =3D __copy_from_user_inatomic(vaddr + pg, user_data, len); - kunmap_atomic(vaddr); + pagefault_enable(); + kunmap_local(vaddr); =20 err =3D aops->write_end(obj->base.filp, mapping, offset, len, len - unwritten, page, data); --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46C5EC77B61 for ; Wed, 29 Mar 2023 07:25:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230074AbjC2HZF (ORCPT ); Wed, 29 Mar 2023 03:25:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229975AbjC2HYg (ORCPT ); Wed, 29 Mar 2023 03:24:36 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F017430F1 for ; Wed, 29 Mar 2023 00:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074674; x=1711610674; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=O5mjsJvXEoxA+vJsVu0W75jJyr6KhRreGwElbH0Raj8=; b=Ea6wj8SwifeBVQ3Wd9XmbJZrskQpS04HhP7cx1CiU7sGBZCTtNbyJFFV Sm9JBRywvMLY0G0QhAv568XF+JFC3pxDgmj9daylZGacGql11dXS9nzdj gfcaUsMpyDaAgCgLVlgeUe7z+NrFDY14wPv2Ejk64Kl4Y0GuHUrx6XlY9 sHTi6w4fUva7xEmtj9WwIFlcb4/S4auhMHAvxw0bEw4GwvNz0LwHgQ0Ln S+g5JZi6+UntvvZcRPU4OEmzJgrKTKywhHCA8QvsX04+Z6K/1emrhqoM5 nQifsddr2e6+0vtcH9ijOTUfeoFIpIJh4+iBQCyhXCFN4JGH8MXaQ33Nn A==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405745920" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405745920" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160581" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160581" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:29 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 4/9] drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c Date: Wed, 29 Mar 2023 15:32:15 +0800 Message-Id: <20230329073220.3982460-5-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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 Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/= drm/i915/gem/selftests/huge_pages.c index defece0bcb81..3f9ea48a48d0 100644 --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c @@ -1026,7 +1026,7 @@ __cpu_check_shmem(struct drm_i915_gem_object *obj, u3= 2 dword, u32 val) goto err_unlock; =20 for (n =3D 0; n < obj->base.size >> PAGE_SHIFT; ++n) { - u32 *ptr =3D kmap_atomic(i915_gem_object_get_page(obj, n)); + u32 *ptr =3D kmap_local_page(i915_gem_object_get_page(obj, n)); =20 if (needs_flush & CLFLUSH_BEFORE) drm_clflush_virt_range(ptr, PAGE_SIZE); @@ -1034,12 +1034,12 @@ __cpu_check_shmem(struct drm_i915_gem_object *obj, = u32 dword, u32 val) if (ptr[dword] !=3D val) { pr_err("n=3D%lu ptr[%u]=3D%u, val=3D%u\n", n, dword, ptr[dword], val); - kunmap_atomic(ptr); + kunmap_local(ptr); err =3D -EINVAL; break; } =20 - kunmap_atomic(ptr); + kunmap_local(ptr); } =20 i915_gem_object_finish_access(obj); --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43D0DC77B6D for ; Wed, 29 Mar 2023 07:25:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230089AbjC2HZa (ORCPT ); Wed, 29 Mar 2023 03:25:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230062AbjC2HZE (ORCPT ); Wed, 29 Mar 2023 03:25:04 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B84D33AAB for ; Wed, 29 Mar 2023 00:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074689; x=1711610689; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=eFmVjsv1DCN0/J2TIleZPCjZ8XDr2WxmZ0GRJxV4ib4=; b=MpYoHoxw9PEqj+2dJV4c16PeWhTrcRwRmIQdY9HLSWfKMY3N2xrT49JR lTRD9KE3HKEDMZ1BDqWm4Ti20HxGK9F6iB2fDK9b5z2oVCiHxBbanriT9 +zIUcBLtQDmGHB8ilsnu0GVqtKB5Ohc4tToxl3/qbIy1KbK2pPuoRAxLu FpvgwGGnbdST+y7sgEKuKOFkQLMajUeWNJztX9qrvrV0zPqAvwhR484jo ppl4rMoL4ZthsV3+fwidt/lfwbtdcLqAhRXaPk4UqIAukHJdayiWwl7OB 2UwtQYklg6WwVmmpGtUafbIOkQHzBTeW+mCrm+RNxIDgV6rgS/LIgGwfk w==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405746032" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405746032" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160597" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160597" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:34 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 5/9] drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c Date: Wed, 29 Mar 2023 15:32:16 +0800 Message-Id: <20230329073220.3982460-6-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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/i915_gem_coherency.c, functions cpu_set() and cpu_get() mainly uses mapping to flush cache and assign the value. There're 2 reasons why cpu_set() and cpu_get() don't need to disable pagefaults and preemption for mapping: 1. The flush operation is safe. cpu_set() and cpu_get() call 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_set() and cpu_get() are 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/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 Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. --- .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c b/driv= ers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c index 3bef1beec7cb..beeb3e12eccc 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c @@ -24,7 +24,6 @@ static int cpu_set(struct context *ctx, unsigned long off= set, u32 v) { unsigned int needs_clflush; struct page *page; - void *map; u32 *cpu; int err; =20 @@ -34,8 +33,7 @@ static int cpu_set(struct context *ctx, unsigned long off= set, u32 v) goto out; =20 page =3D i915_gem_object_get_page(ctx->obj, offset >> PAGE_SHIFT); - map =3D kmap_atomic(page); - cpu =3D map + offset_in_page(offset); + cpu =3D kmap_local_page(page) + offset_in_page(offset); =20 if (needs_clflush & CLFLUSH_BEFORE) drm_clflush_virt_range(cpu, sizeof(*cpu)); @@ -45,7 +43,7 @@ static int cpu_set(struct context *ctx, unsigned long off= set, u32 v) if (needs_clflush & CLFLUSH_AFTER) drm_clflush_virt_range(cpu, sizeof(*cpu)); =20 - kunmap_atomic(map); + kunmap_local(cpu); i915_gem_object_finish_access(ctx->obj); =20 out: @@ -57,7 +55,6 @@ static int cpu_get(struct context *ctx, unsigned long off= set, u32 *v) { unsigned int needs_clflush; struct page *page; - void *map; u32 *cpu; int err; =20 @@ -67,15 +64,14 @@ static int cpu_get(struct context *ctx, unsigned long o= ffset, u32 *v) goto out; =20 page =3D i915_gem_object_get_page(ctx->obj, offset >> PAGE_SHIFT); - map =3D kmap_atomic(page); - cpu =3D map + offset_in_page(offset); + cpu =3D kmap_local_page(page) + offset_in_page(offset); =20 if (needs_clflush & CLFLUSH_BEFORE) drm_clflush_virt_range(cpu, sizeof(*cpu)); =20 *v =3D *cpu; =20 - kunmap_atomic(map); + kunmap_local(cpu); i915_gem_object_finish_access(ctx->obj); =20 out: --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22924C6FD18 for ; Wed, 29 Mar 2023 07:26:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230121AbjC2HZ7 (ORCPT ); Wed, 29 Mar 2023 03:25:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230041AbjC2HZR (ORCPT ); Wed, 29 Mar 2023 03:25:17 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0191448B for ; Wed, 29 Mar 2023 00:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074700; x=1711610700; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GMpKo8ThZ2YBrIiNDv5DIUoRW6Piin/4x6sH+rZpkMU=; b=N8SOof7zkbbECzwuzNHEYGNELDAnjm5FRzrTaUH5Vn4ILm5YOuPPd4u3 ttZa/H3J04Wf/rFzSypUwdJtxSnserWGnIkCLKbSMOFzim5LHBp2XhwU7 BMbPG2mwwaL7IUpgwgzBg+RIyzAoeNt2dgaZb/XOFxZ6yuJINj7qthM6R xtjdnZc2il0tckucZ90KWT4MNkGPZCOmJgC5nadikl1nBUFKJ3EmxsGJz DcPotdxbUzHDveF8w9QroLy4Eltnr4zqUnvqIqFu8OQEHyr7u+J83g2w8 CNF1uylvzPYib24AMAFbHJlMCFanf2DJ0IJnTUIuTbwr48oKovs3hfHkQ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405746125" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405746125" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160621" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160621" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:40 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 6/9] drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c Date: Wed, 29 Mar 2023 15:32:17 +0800 Message-Id: <20230329073220.3982460-7-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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. With kmap_local_page(), we can avoid the often unwanted side effect of unnecessary page faults or preemption disables. In drm/i915/gem/selftests/i915_gem_context.c, functions cpu_fill() and cpu_check() mainly uses mapping to flush cache and check/assign the value. There're 2 reasons why cpu_fill() and cpu_check() don't need to disable pagefaults and preemption for mapping: 1. The flush operation is safe. cpu_fill() and cpu_check() call 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_fill() and cpu_check() are 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/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 Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/driver= s/gpu/drm/i915/gem/selftests/i915_gem_context.c index a81fa6a20f5a..dcbc0b8e3323 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c @@ -481,12 +481,12 @@ static int cpu_fill(struct drm_i915_gem_object *obj, = u32 value) for (n =3D 0; n < real_page_count(obj); n++) { u32 *map; =20 - map =3D kmap_atomic(i915_gem_object_get_page(obj, n)); + map =3D kmap_local_page(i915_gem_object_get_page(obj, n)); for (m =3D 0; m < DW_PER_PAGE; m++) map[m] =3D value; if (!has_llc) drm_clflush_virt_range(map, PAGE_SIZE); - kunmap_atomic(map); + kunmap_local(map); } =20 i915_gem_object_finish_access(obj); @@ -512,7 +512,7 @@ static noinline int cpu_check(struct drm_i915_gem_objec= t *obj, for (n =3D 0; n < real_page_count(obj); n++) { u32 *map, m; =20 - map =3D kmap_atomic(i915_gem_object_get_page(obj, n)); + map =3D kmap_local_page(i915_gem_object_get_page(obj, n)); if (needs_flush & CLFLUSH_BEFORE) drm_clflush_virt_range(map, PAGE_SIZE); =20 @@ -538,7 +538,7 @@ static noinline int cpu_check(struct drm_i915_gem_objec= t *obj, } =20 out_unmap: - kunmap_atomic(map); + kunmap_local(map); if (err) break; } --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32CE7C74A5B for ; Wed, 29 Mar 2023 07:26:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230103AbjC2H0Y (ORCPT ); Wed, 29 Mar 2023 03:26:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230081AbjC2HZa (ORCPT ); Wed, 29 Mar 2023 03:25:30 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71233423B for ; Wed, 29 Mar 2023 00:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074708; x=1711610708; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ctlg4NjY5kelpxf9KaNbuOy8AYhBpUiiPegXpU79lsk=; b=MplV/1d5rX06izKHPIC9ImyCC276YMdX/42K1yTOn/WziPWxj0Cr9VtW fW/8PfWhQx/LHCGB56zkYTQZ+WE6XukeN6VcZLkzoYMzIw6Ey44xLEY4C gTc9cT//kv8Rb+Qcnx+nSLz60PKZYYRLMPkeGVsS4j5BZwfCfBluYxHsY IHoWBJ5Hl0Jt6qhSm7yfNHKmxUaIN2yaZ5ECtcLzG//5TAMxazyP9df97 2G7wZ7O8PxLRbFGNk3ZYAjLdiJPr/3eO5Dxb9TvL7lPfJIn3yC995V1Ar Gk+UOiPW2wdlvxzCVhsXP5qDgkc32/HZXS3/E1m1hfPywRMyJlFp6oICm Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405746202" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405746202" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160631" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160631" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:45 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu Subject: [PATCH v2 7/9] drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c Date: Wed, 29 Mar 2023 15:32:18 +0800 Message-Id: <20230329073220.3982460-8-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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/gt/uc/intel_us_fw.c, the function intel_uc_fw_copy_rsa() just use the mapping to do memory copy so it doesn't need to disable pagefaults and preemption for mapping. Thus the local mapping without atomic context (not disable pagefaults / preemption) is enough. Therefore, intel_uc_fw_copy_rsa() is a function where the use of memcpy_from_page() with kmap_local_page() in place of memcpy() with kmap_atomic() is correctly suited. Convert the calls of memcpy() with kmap_atomic() / kunmap_atomic() to memcpy_from_page() which uses local mapping to copy. [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.co= m/T/#u v2: No code change since v1, and added description of the motivation of using kmap_local_page(). Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Reviewed-by: Ira Weiny Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco --- Suggested by credits: Ira: Referred to his task document and suggestions about using memcpy_from_page() directly. Fabio: Referred to his boiler plate commit message and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i91= 5/gt/uc/intel_uc_fw.c index 65672ff82605..5bbde4abd565 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -1152,16 +1152,13 @@ size_t intel_uc_fw_copy_rsa(struct intel_uc_fw *uc_= fw, void *dst, u32 max_len) =20 for_each_sgt_page(page, iter, uc_fw->obj->mm.pages) { u32 len =3D min_t(u32, size, PAGE_SIZE - offset); - void *vaddr; =20 if (idx > 0) { idx--; continue; } =20 - vaddr =3D kmap_atomic(page); - memcpy(dst, vaddr + offset, len); - kunmap_atomic(vaddr); + memcpy_from_page(dst, page, offset, len); =20 offset =3D 0; dst +=3D len; --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0869C74A5B for ; Wed, 29 Mar 2023 07:27:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230038AbjC2H1C (ORCPT ); Wed, 29 Mar 2023 03:27:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230005AbjC2H0T (ORCPT ); Wed, 29 Mar 2023 03:26:19 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A510830D5 for ; Wed, 29 Mar 2023 00:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074726; x=1711610726; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yyQdMm9uqDdypEaS6stlmLE4TXLEkbMEIetdKqrgHwo=; b=Y06uoloSWtxNP2nLpLOYMCuljv+FzsetuSWWfRNvftX6q2574Ivl4uJx SnEIkmcp9uVcYH0C1vlZnYT+EEFA/MkfEmNNWGhR9n9ASPHLEwwgvTg30 /DavM9++tmxmug5dZqEf8j8oc2igA6Wv/GkF2m+KhrX6mRAgJ8BCJSEJY 446CGeSupARiqf5tHDNJniqEfXC4WxAy/dnwco7tTJ5mec/8uxETw0gv0 d4XvQK90WTlCBJoNhAxbeObYioleJPgjRYcYVYt8cDWrE4Y3Fmj0tZH6t tevegI+8WZeMm3jdA3lJmZFZTwOHStXu9Sl6I+hjJ2b5QTU8MWNfO4jwT A==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405746224" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405746224" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:24:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160648" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160648" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:50 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu , Dave Hansen Subject: [PATCH v2 8/9] drm/i915: Use kmap_local_page() in i915_cmd_parser.c Date: Wed, 29 Mar 2023 15:32:19 +0800 Message-Id: <20230329073220.3982460-9-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu 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 and preemption disables. There're 2 reasons why function copy_batch() doesn't need to disable pagefaults and preemption for mapping: 1. The flush operation is safe. In i915_cmd_parser.c, copy_batch() 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, copy_batch() 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 Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco Reviewed-by: Ira Weiny --- 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 and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/= i915_cmd_parser.c index ddf49c2dbb91..2905df83e180 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -1211,11 +1211,11 @@ static u32 *copy_batch(struct drm_i915_gem_object *= dst_obj, for (n =3D offset >> PAGE_SHIFT; remain; n++) { int len =3D min(remain, PAGE_SIZE - x); =20 - src =3D kmap_atomic(i915_gem_object_get_page(src_obj, n)); + src =3D kmap_local_page(i915_gem_object_get_page(src_obj, n)); if (src_needs_clflush) drm_clflush_virt_range(src + x, len); memcpy(ptr, src + x, len); - kunmap_atomic(src); + kunmap_local(src); =20 ptr +=3D len; remain -=3D len; --=20 2.34.1 From nobody Tue Feb 10 00:22:26 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63885C761AF for ; Wed, 29 Mar 2023 07:26:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230139AbjC2H0f (ORCPT ); Wed, 29 Mar 2023 03:26:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230112AbjC2HZ4 (ORCPT ); Wed, 29 Mar 2023 03:25:56 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3A4C40D3 for ; Wed, 29 Mar 2023 00:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074711; x=1711610711; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=rjnVmGthyA2AoK36NNkda5pFc1ytlDwIEHuVtO8n3xE=; b=FLc6yL2n5lGbdZsXJB8Wcz7ATWiSd9wsBdKUBFpFZvL1jBr4/A4Rr1Yp FTqll7vWBRpy79G86zGyoIfqB4tlSCz5r+kYLjVs18beoyBowTW1rwpvQ EeQ8O0O4MyiysTmd/3iO0JYyEoU0Ani0V/Yd5IVXOHXw7j/iJupOKBf6b E3pEeK5pj+lU5RNZEvjIayoIH3FWD+HYYBeFdxOOh5xErf9lTvI5nvPNW Lg8riQ3GvDx2UDMcwU2//uGdYuyCCcNdbslP2/FQneAuWI3q3dSM27xlF cU1VUoRhXjaeJ8XEYlP54rGLrfSt2f9UJJFJvGUy/KNfvnx6XuF3VJoC9 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405746233" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405746233" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2023 00:25:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160663" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160663" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:55 -0700 From: Zhao Liu To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Daniel Vetter , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Nirmoy Das , Maarten Lankhorst , Chris Wilson , =?UTF-8?q?Christian=20K=C3=B6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny , "Fabio M . De Francesco" , Zhenyu Wang , Zhao Liu Subject: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c Date: Wed, 29 Mar 2023 15:32:20 +0800 Message-Id: <20230329073220.3982460-10-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> References: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhao Liu The use of kmap_atomic() is being deprecated in favor of kmap_local_page()[1], and this patch converts the calls 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 and preemption disables. In i915_gem_execbuffer.c, eb->reloc_cache.vaddr is mapped by kmap_atomic() in eb_relocate_entry(), and is unmapped by kunmap_atomic() in reloc_cache_reset(). And this mapping/unmapping occurs in two places: one is in eb_relocate_vma(), and another is in eb_relocate_vma_slow(). The function eb_relocate_vma() or eb_relocate_vma_slow() doesn't need to disable pagefaults and preemption during the above mapping/ unmapping. So it can simply use kmap_local_page() / kunmap_local() that can instead do the mapping / unmapping regardless of the context. 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: No code change since v1. Added description of the motivation of using kmap_local_page() and "Suggested-by" tag of Fabio. Suggested-by: Ira Weiny Suggested-by: Fabio M. De Francesco Signed-off-by: Zhao Liu Reviewed-by: Fabio M. De Francesco --- Suggested by credits: Ira: Referred to his task document, review comments. Fabio: Referred to his boiler plate commit message and his description about why kmap_local_page() should be preferred. --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/d= rm/i915/gem/i915_gem_execbuffer.c index 9dce2957b4e5..805565edd148 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1151,7 +1151,7 @@ static void reloc_cache_unmap(struct reloc_cache *cac= he) =20 vaddr =3D unmask_page(cache->vaddr); if (cache->vaddr & KMAP) - kunmap_atomic(vaddr); + kunmap_local(vaddr); else io_mapping_unmap_atomic((void __iomem *)vaddr); } @@ -1167,7 +1167,7 @@ static void reloc_cache_remap(struct reloc_cache *cac= he, if (cache->vaddr & KMAP) { struct page *page =3D i915_gem_object_get_page(obj, cache->page); =20 - vaddr =3D kmap_atomic(page); + vaddr =3D kmap_local_page(page); cache->vaddr =3D unmask_flags(cache->vaddr) | (unsigned long)vaddr; } else { @@ -1197,7 +1197,7 @@ static void reloc_cache_reset(struct reloc_cache *cac= he, struct i915_execbuffer if (cache->vaddr & CLFLUSH_AFTER) mb(); =20 - kunmap_atomic(vaddr); + kunmap_local(vaddr); i915_gem_object_finish_access(obj); } else { struct i915_ggtt *ggtt =3D cache_to_ggtt(cache); @@ -1229,7 +1229,7 @@ static void *reloc_kmap(struct drm_i915_gem_object *o= bj, struct page *page; =20 if (cache->vaddr) { - kunmap_atomic(unmask_page(cache->vaddr)); + kunmap_local(unmask_page(cache->vaddr)); } else { unsigned int flushes; int err; @@ -1251,7 +1251,7 @@ static void *reloc_kmap(struct drm_i915_gem_object *o= bj, if (!obj->mm.dirty) set_page_dirty(page); =20 - vaddr =3D kmap_atomic(page); + vaddr =3D kmap_local_page(page); cache->vaddr =3D unmask_flags(cache->vaddr) | (unsigned long)vaddr; cache->page =3D pageno; =20 --=20 2.34.1