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@xxxxxxxxx> > 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@xxxxxxxxx> > > > > 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
