From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Will Deacon <will@kernel.org>,
Peter Collingbourne <pcc@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, outreachy@lists.linux.dev,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 3/4] Documentation/vm: Remove "Using kmap-atomic" from highmem.rst.
Date: Fri, 22 Apr 2022 22:09:03 +0200 [thread overview]
Message-ID: <2370538.jE0xQCEvom@leap> (raw)
In-Reply-To: <YmL2EQhfQLMoU1WV@iweiny-desk3>
On venerdì 22 aprile 2022 20:38:09 CEST Ira Weiny wrote:
> On Thu, Apr 21, 2022 at 08:01:59PM +0200, Fabio M. De Francesco wrote:
> > The use of kmap_atomic() is deprecated in favor of kmap_local_page().
>
> I'm not sure deprecated is the right word.
OK, in v2 I won't use "deprecated". Instead I'll say something about a
strong preference to avoid its use. The reason why developers should avoid
kmap_atomic() are explained in 4/4 (I've copy-pasted some lines here for
your convenience):
+ Each call of kmap_atomic() in the kernel creates a non-preemptible
section
+ and disable pagefaults. This could be a source of unwanted latency, so
it
+ should be only used if it is absolutely required, otherwise
kmap_local_page()
+ should be used where it is feasible.
> And I think the fact that this
> documentation is stale is a better reason for the patch as is.
>
> This series should end up indicating the desire to stop growing kmap()
and
> kmap_atomic() call sites and that their deprecation is on the horizon.
I've
> not read the text in patch 4/4 yet.
I'll wait for your review of 4/4 before sending v2.
>
> > For
> > this reason the "Using kmap_atomic" section in highmem.rst is obsolete
and
> > unnecessary.
>
> A lot of the text is obsolete (and redundant) but the example code might
be
> useful.
>
> Why not move the example and relevant bits into the kdoc for
kmap_atomic()
> which is then automatically picked up via patch 2/4.
Yes, I agree with you. I'll take into account your suggestion for v2.
However, as I said above, I'll hold v2 until you have time to review 4/4
for the purpose to not miss any changes that you might require for that
patch too.
Furthermore, while working on v2, I think that I'll extend this series with
one or two patch more, in order to address other issues I noticed.
Thanks,
Fabio
next prev parent reply other threads:[~2022-04-22 21:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 18:01 [PATCH 0/4] Extend and reorganize Highmem's documentation Fabio M. De Francesco
2022-04-21 18:01 ` [PATCH 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Fabio M. De Francesco
2022-04-22 8:24 ` Mike Rapoport
2022-04-22 9:36 ` Fabio M. De Francesco
2022-04-22 10:32 ` Mike Rapoport
2022-04-22 18:08 ` Ira Weiny
2022-04-22 20:42 ` Fabio M. De Francesco
2022-04-21 18:01 ` [PATCH 2/4] Documentation/vm: Include kdocs from highmem*.h into highmem.rst Fabio M. De Francesco
2022-04-22 8:33 ` Mike Rapoport
2022-04-22 18:09 ` Ira Weiny
2022-04-21 18:01 ` [PATCH 3/4] Documentation/vm: Remove "Using kmap-atomic" from highmem.rst Fabio M. De Francesco
2022-04-22 18:38 ` Ira Weiny
2022-04-22 20:09 ` Fabio M. De Francesco [this message]
2022-04-21 18:02 ` [PATCH 4/4] Documentation/vm: Rework "Temporary Virtual Mappings" Fabio M. De Francesco
2022-04-25 0:59 ` Ira Weiny
2022-04-25 1:42 ` Fabio M. De Francesco
2022-04-25 2:05 ` Fabio M. De Francesco
2022-04-25 16:51 ` Ira Weiny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2370538.jE0xQCEvom@leap \
--to=fmdefrancesco@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=ira.weiny@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=outreachy@lists.linux.dev \
--cc=pcc@google.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.