Message ID | 20230329073220.3982460-1-zhao1.liu@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp224477vqo; Wed, 29 Mar 2023 00:26:28 -0700 (PDT) X-Google-Smtp-Source: AKy350a61bt9ix0beZdSqbAdHP5bxdTdfL19jY0tIjADqoWW6LJpExql36YnFuvZ+4D5fAwteDiJ X-Received: by 2002:a17:906:90c9:b0:933:6ae6:374d with SMTP id v9-20020a17090690c900b009336ae6374dmr15990468ejw.73.1680074788109; Wed, 29 Mar 2023 00:26:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680074788; cv=none; d=google.com; s=arc-20160816; b=ZkKbP744BtvpS++D23ObRvp2V++YjSzzGbfXFY/RqLmpbjMdGLBHaY+6rBHeOl7SQl mgNph7VFIqM9fB7LDjOz2tqQphYyxF6dNfikIbGj5pFGDHNdPPFlH3e7XlLXvFFxzR0V KRW6FoTUFHSJALyPZO+TGelhklAzD8o57D5fLVcvZ25w5r63gU5qptXmxVrcb0MiR+S5 DeUhqe2ggnIDBRH5wlUPF9pXwXvj88PSib5SSGMxqke/9dH4iAweQfDjpKRoAyZ6ZoAp 4Luhke8tPUhO5MAkedk0j0V53Oyc8dkxe5Y2mzztdKI5EKi6kDnPJbYc8sCCpzFr19Su QDbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=yT5GZVOvhfnUIBY2ARE+vAtUXWQaZu9+y3E6YcXmSew=; b=BZVRAC+xbBKjZFDSpYeJijPxCVTyZAUaFnryfp7ZJjDfyUBHlDyBmm0xI9pkJHfcli C08ZySGhvu8GQuuSgtS27MoB/qx8FfUwakxI/j3kt7j+NbcSpcl1Pk0JJammPeJbIqG7 m8VQ7yR6/cP9RMF7hNfDCaTd44GrsYm26ZgYMm4SiYG0EOvbH+AFVC6GWE9QD0wR93jt T+FEs1AO6PTrYK8VkBSLeHRpTR3qI9Wlf6Ti8vwoVCApubcKOqzwuxXN/vvfF69jeDty 6cqYhm6EikftFaLWkuN/SRCSuy+SWvSqJ4noeomoFMdrBMQOHVnjhzsztMbGR4lOVMdL 3jpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=dPLqZ93q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f25-20020a17090631d900b0092c8da1e5edsi33124995ejf.611.2023.03.29.00.26.03; Wed, 29 Mar 2023 00:26:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=dPLqZ93q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229973AbjC2HYg (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 03:24:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229972AbjC2HYR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 03:24:17 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9C081BF6 for <linux-kernel@vger.kernel.org>; Wed, 29 Mar 2023 00:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680074654; x=1711610654; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=ggmwxoc7/dils5MWJi70ypc6lFx8cadwyL7s3JUR9cA=; b=dPLqZ93q/44tUma7uapeVHve6LICMIcBKF5uBV9No+MIZaMY/7Kwguj0 zxJdV1bm1dvtygN6+syq5BNVzJTnqqWoshA/d8lQHBCoxkrm0E+Vp2Al0 l5G466JquhoFlhKyKlOJ2JIQc5rKWk//QvyAbcE58PCPhKPTAKnBkLsLM dmMgxx/3YMU5HPHqpTK1XKYuLK+JFOe7XB+rITuyUVLp9LdQS4QCLPyoR XkV+bseLAtTbWbfGetBsWs1SVG2RwVZ0FAlvsvavdel1IpeZk1tF3nKAT F2hPPjiYUyCd+VMCsZQ1+E7wIkMTlzi9o4dpIbxJYv4MAnDZTBcxOYpdK w==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="405745830" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="405745830" 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:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="684160540" X-IronPort-AV: E=Sophos;i="5.98,300,1673942400"; d="scan'208";a="684160540" Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.112]) by orsmga002.jf.intel.com with ESMTP; 29 Mar 2023 00:24:09 -0700 From: Zhao Liu <zhao1.liu@linux.intel.com> To: Jani Nikula <jani.nikula@linux.intel.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Matthew Auld <matthew.auld@intel.com>, =?utf-8?q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>, Nirmoy Das <nirmoy.das@intel.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Chris Wilson <chris@chris-wilson.co.uk>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: Ira Weiny <ira.weiny@intel.com>, "Fabio M . De Francesco" <fmdefrancesco@gmail.com>, Zhenyu Wang <zhenyu.z.wang@intel.com>, Zhao Liu <zhao1.liu@intel.com> Subject: [PATCH v2 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page() Date: Wed, 29 Mar 2023 15:32:11 +0800 Message-Id: <20230329073220.3982460-1-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761686100884898595?= X-GMAIL-MSGID: =?utf-8?q?1761686100884898595?= |
Series |
drm/i915: Replace kmap_atomic() with kmap_local_page()
|
|
Message
Zhao Liu
March 29, 2023, 7:32 a.m. UTC
From: Zhao Liu <zhao1.liu@intel.com>
Hi list,
Sorry for a long delay since v1 [1]. This patchset is based on 197b6b6
(Linux 6.3-rc4).
Welcome and thanks for your review and comments!
# Purpose of this patchset
The purpose of this pacthset is to replace all uses of kmap_atomic() in
i915 with kmap_local_page() because the use of kmap_atomic() is being
deprecated in favor of kmap_local_page()[1]. And 92b64bd (mm/highmem:
add notes about conversions from kmap{,_atomic}()) has declared the
deprecation of kmap_atomic().
# Motivation for deprecating kmap_atomic() and using 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.
# Patch summary
Patch 1, 4-6 and 8-9 replace kamp_atomic()/kunmap_atomic() with
kmap_local_page()/kunmap_local() directly. With thses local
mappings, the page faults and preemption are allowed.
Patch 2 and 7 use memcpy_from_page() and memcpy_to_page() to replace
kamp_atomic()/kunmap_atomic(). These two variants of memcpy()
are based on the local mapping, so page faults and preemption
are also allowed in these two interfaces.
Patch 3 replaces kamp_atomic()/kunmap_atomic() with kmap_local_page()/
kunmap_local() and also diable page fault since the for special
handling (pls see the commit message).
# Changes since v1
* Dropped hot plug related description in commit message since it has
nothing to do with kmap_local_page().
* Emphasized the motivation for using kmap_local_page() in commit
message.
* Rebased patch 1 on f47e630 (drm/i915/gem: Typecheck page lookups) to
keep the "idx" variable of type pgoff_t here.
* Used memcpy_from_page() and memcpy_to_page() to replace
kmap_local_page() + memcpy() in patch 2.
# Reference
[1]: https://lore.kernel.org/lkml/20221017093726.2070674-1-zhao1.liu@linux.intel.com/
[1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com
---
Zhao Liu (9):
drm/i915: Use kmap_local_page() in gem/i915_gem_object.c
drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c
drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c
drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c
drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c
drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c
drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c
drm/i915: Use kmap_local_page() in i915_cmd_parser.c
drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++++-----
drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++-----
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 10 ++--------
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++---
.../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 ++++--------
.../gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 ++++----
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +----
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
9 files changed, 28 insertions(+), 41 deletions(-)
Comments
On mercoledì 29 marzo 2023 09:32:11 CEST Zhao Liu wrote: > From: Zhao Liu <zhao1.liu@intel.com> > > Hi list, > > Sorry for a long delay since v1 [1]. This patchset is based on 197b6b6 > (Linux 6.3-rc4). > > Welcome and thanks for your review and comments! > > > # Purpose of this patchset > > The purpose of this pacthset is to replace all uses of kmap_atomic() in > i915 with kmap_local_page() because the use of kmap_atomic() is being > deprecated in favor of kmap_local_page()[1]. And 92b64bd (mm/highmem: > add notes about conversions from kmap{,_atomic}()) has declared the > deprecation of kmap_atomic(). > > > # Motivation for deprecating kmap_atomic() and using 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. > > > # Patch summary > > Patch 1, 4-6 and 8-9 replace kamp_atomic()/kunmap_atomic() with > kmap_local_page()/kunmap_local() directly. With thses local > mappings, the page faults and preemption are allowed. > > Patch 2 and 7 use memcpy_from_page() and memcpy_to_page() to replace > kamp_atomic()/kunmap_atomic(). These two variants of memcpy() > are based on the local mapping, so page faults and preemption > are also allowed in these two interfaces. > > Patch 3 replaces kamp_atomic()/kunmap_atomic() with kmap_local_page()/ > kunmap_local() and also diable page fault since the for special > handling (pls see the commit message). > > > # Changes since v1 > > * Dropped hot plug related description in commit message since it has > nothing to do with kmap_local_page(). > * Emphasized the motivation for using kmap_local_page() in commit > message. > * Rebased patch 1 on f47e630 (drm/i915/gem: Typecheck page lookups) to > keep the "idx" variable of type pgoff_t here. > * Used memcpy_from_page() and memcpy_to_page() to replace > kmap_local_page() + memcpy() in patch 2. > > > # Reference > > [1]: > https://lore.kernel.org/lkml/20221017093726.2070674-1-zhao1.liu@linux.intel.c > om/ [1]: > https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com --- > Zhao Liu (9): > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > I _think_ that the "long delay" you mentioned in the first sentence has paid off in full. I don't see things to improve (except all those "kamp_atomic()" typo in the patches summary; however, typos are only in the cover so I'm sure they won't hurt anybody). Each of the nine patches listed above looks good to me, so they are all… Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Thanks! Fabio PS: Obviously there was no need to reconfirm my tag for patch 3/9. A single tag that catches all patches is easier for a lazy person like me :-) > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++++----- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++----- > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 10 ++-------- > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++++-- > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 ++++-------- > .../gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 ++++---- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +---- > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > 9 files changed, 28 insertions(+), 41 deletions(-) > > -- > 2.34.1
Hi Fabio, On Wed, Mar 29, 2023 at 06:03:38PM +0200, Fabio M. De Francesco wrote: > Date: Wed, 29 Mar 2023 18:03:38 +0200 > From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com> > Subject: Re: [PATCH v2 0/9] drm/i915: Replace kmap_atomic() with > kmap_local_page() > > On mercoledì 29 marzo 2023 09:32:11 CEST Zhao Liu wrote: > > From: Zhao Liu <zhao1.liu@intel.com> > > > > Hi list, > > > > Sorry for a long delay since v1 [1]. This patchset is based on 197b6b6 > > (Linux 6.3-rc4). > > > > Welcome and thanks for your review and comments! > > > > > > # Purpose of this patchset > > > > The purpose of this pacthset is to replace all uses of kmap_atomic() in > > i915 with kmap_local_page() because the use of kmap_atomic() is being > > deprecated in favor of kmap_local_page()[1]. And 92b64bd (mm/highmem: > > add notes about conversions from kmap{,_atomic}()) has declared the > > deprecation of kmap_atomic(). > > > > > > # Motivation for deprecating kmap_atomic() and using 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. > > > > > > # Patch summary > > > > Patch 1, 4-6 and 8-9 replace kamp_atomic()/kunmap_atomic() with > > kmap_local_page()/kunmap_local() directly. With thses local > > mappings, the page faults and preemption are allowed. > > > > Patch 2 and 7 use memcpy_from_page() and memcpy_to_page() to replace > > kamp_atomic()/kunmap_atomic(). These two variants of memcpy() > > are based on the local mapping, so page faults and preemption > > are also allowed in these two interfaces. > > > > Patch 3 replaces kamp_atomic()/kunmap_atomic() with kmap_local_page()/ > > kunmap_local() and also diable page fault since the for special > > handling (pls see the commit message). > > > > > > # Changes since v1 > > > > * Dropped hot plug related description in commit message since it has > > nothing to do with kmap_local_page(). > > * Emphasized the motivation for using kmap_local_page() in commit > > message. > > * Rebased patch 1 on f47e630 (drm/i915/gem: Typecheck page lookups) to > > keep the "idx" variable of type pgoff_t here. > > * Used memcpy_from_page() and memcpy_to_page() to replace > > kmap_local_page() + memcpy() in patch 2. > > > > > > # Reference > > > > [1]: > > https://lore.kernel.org/lkml/20221017093726.2070674-1-zhao1.liu@linux.intel.c > > om/ [1]: > > https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com --- > > Zhao Liu (9): > > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > > drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > > > > I _think_ that the "long delay" you mentioned in the first sentence has paid > off in full. > > I don't see things to improve (except all those "kamp_atomic()" typo in the > patches summary; however, typos are only in the cover so I'm sure they won't > hurt anybody). Thanks a lot for your patience and your help! :-) > > Each of the nine patches listed above looks good to me, so they are all… > > Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> > > Thanks! > > Fabio > > PS: Obviously there was no need to reconfirm my tag for patch 3/9. A single > tag that catches all patches is easier for a lazy person like me :-) The typos and this description still can be improved. I'll pay attention in the future! Thanks, Zhao > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++++----- > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++----- > > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 10 ++-------- > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++++-- > > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 ++++-------- > > .../gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 ++++---- > > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +---- > > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > > 9 files changed, 28 insertions(+), 41 deletions(-) > > > > -- > > 2.34.1 > > > >