[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2TtAAqSyAgTVIL8@liuzhao-OptiPlex-7080>
Date: Fri, 4 Nov 2022 18:44:16 +0800
From: Zhao Liu <zhao1.liu@...ux.intel.com>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Matthew Auld <matthew.auld@...el.com>,
Thomas Hellström
<thomas.hellstrom@...ux.intel.com>,
Nirmoy Das <nirmoy.das@...el.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Chris Wilson <chris@...is-wilson.co.uk>,
Christian König <christian.koenig@....com>,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, Ira Weiny <ira.weiny@...el.com>,
"Fabio M . De Francesco" <fmdefrancesco@...il.com>,
Zhenyu Wang <zhenyu.z.wang@...el.com>,
Zhao Liu <zhao1.liu@...el.com>
Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with
kmap_local_page()
On Sat, Oct 29, 2022 at 09:12:27AM +0200, Fabio M. De Francesco wrote:
> Date: Sat, 29 Oct 2022 09:12:27 +0200
> From: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
> Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with
> kmap_local_page()
Hi Fabio, thanks for your review!! (I'm sorry I missed the previous mails).
>
> On luned? 17 ottobre 2022 11:37:16 CEST Zhao Liu wrote:
> > From: Zhao Liu <zhao1.liu@...el.com>
> >
> > The use of kmap_atomic() is being deprecated in favor of
> > kmap_local_page()[1].
>
> Some words to explain why kmap_atomic was deprecated won't hurt. Many
> maintainers and reviewers, and also casual readers might not yet be aware of
> the reasons behind that deprecation.
>
> > In the following patches, we can convert the calls of kmap_atomic() /
> > kunmap_atomic() to kmap_local_page() / kunmap_local(), which can
> > instead do the mapping / unmapping regardless of the context.
>
> Readers are probably much more interested in what you did in the following
> patches and why you did it, instead of being informed about what "we can" do.
>
> I would suggest something like "The following patches convert the calls to
> kmap_atomic() to kmap_local_page() [the rest looks OK]".
>
> This could also be the place to say something about why we prefer
> kmap_local_page() to kmap_atomic().
>
> Are you sure that the reasons that motivates your conversions are merely
> summarized to kmap_local_page() being able to do mappings regardless of
> context? I think you are missing the real reasons why.
Thanks for your reminder, I'll emphasize the motivation here.
> What about avoiding the often unwanted side effect of unnecessary page faults
> disables?
Good suggestion! I'll add this into this cover message.
What I think is that we have two reasons to do the replacement work:
1. (main motication) Avoid unnessary pagefaulta and preemption disabling to gain
performance benefits.
2. We are trying to deprecate the old kmap/kmap_atomic interface. Some maintainer
said it's also a good reason especially for the case that the performance is not
critical [1].
In addition, also from [1], I find in some case people chooses kmap_atomic() for
the consideration that they want the atomic context. So, the explaination about
why the atomic context is not needed is also a reasion? I understand that I need
to make special explaination in each commit depending on the situation (In this
case, it is not suitable to describe in the cover?).
[1]: https://lore.kernel.org/lkml/YzRVaJA0EyfcVisW@liuwe-devbox-debian-v2/#t
>
> >
> > With kmap_local_page(), the mapping is per thread, CPU local and not
> > globally visible.
>
> No news here. kmap_atomic() is "per thread, CPU local and not glocally
> visible". I cannot see any difference here between kmap_atomic() and
> kmap_local_page().
What about the below description which refers to your doc?
"kmap_atomic() in the kernel creates a non-preemptible section
and disable pagefaults. This could be a source of unwanted latency.
And kmap_local_page effectively overcomes this issue because it doesn't
disable pagefault and preemption."
Thanks,
Zhao
Powered by blists - more mailing lists