lkml.org 
[lkml]   [2022]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@gmail.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@intel.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

\
 
 \ /
  Last update: 2022-11-04 11:39    [W:0.246 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site