From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>,
kexec@lists.infradead.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH v2] kexec: Replace kmap() with kmap_local_page()
Date: Tue, 02 Aug 2022 13:02:25 +0200 [thread overview]
Message-ID: <5847084.alqRGMn8q6@opensuse> (raw)
In-Reply-To: <YujTHv0xVG8DirkW@MiWiFi-R3L-srv>
On martedì 2 agosto 2022 09:32:46 CEST Baoquan He wrote:
> On 08/02/22 at 08:20am, Fabio M. De Francesco wrote:
> > On martedì 2 agosto 2022 05:06:54 CEST Baoquan He wrote:
> > > On 07/08/22 at 01:15am, Fabio M. De Francesco wrote:
> > > > The use of kmap() and kmap_atomic() are being deprecated in favor
of
> > > > kmap_local_page().
> > > >
> > > > With kmap_local_page(), the mappings are per thread, CPU local and
not
> > > > globally visible. Furthermore, the mappings can be acquired from
any
> > > > context (including interrupts).
> > > >
> > > > Therefore, use kmap_local_page() in kexec_core.c because these
mappings
> > are
> > > > per thread, CPU local, and not globally visible.
> > > >
> > > > Tested on a QEMU + KVM 32-bits VM booting a kernel with HIGHMEM64GB
> > > > enabled.
> > >
> > > Wondering what arch you tested with.
> >
> > I'm sorry, I forgot to say that I use x86_32 with 4GB to 6GB RAM.
> > This is usually an information that I add in the commit messages of all
the
> > recent conversions I'm working on across the entire kernel.
> >
> > Another important information (overlooked again this time) is that (1)
> > kmap() comes with an overhead as mapping space is restricted and
protected
> > by a global lock for synchronization and (2) it also requires global
TLB
> > invalidation when the kmap’s pool wraps and it might block when the
mapping
> > space is fully utilized until a slot becomes available.
>
> Thanks a lot for update with more details, Fabio.
You're welcome.
> Maybe these can be
> added into log with v3 if you think they are worth adding, and with my
> Ack since no code change related. You decide.
For weeks I've been thinking that these details were not necessary in the
commit message of these conversions. Later I realized that a fair number of
maintainers weren't aware of why we should change something that had been
working "properly" for years. Perhaps they thought that we would face too
many risks of breaking things versus little rewards.
After discussing with Greg K-H (who was initially not fond of these changes
to core parts of firmware loading mechanism), he suggested that a proper
commit log with the necessary information could have helped himself and the
other maintainers who may not yet had time to deepen this topics.
This patch to "kexec" slipped in with no such additions.
Therefore, I agree with you in full: I'll add these information and send a
new version ASAP.
> Thanks again for the effort.
Thanks so much for the "Acked-by:" tag from you.
Fabio
[snip]
prev parent reply other threads:[~2022-08-02 11:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 23:15 [PATCH v2] kexec: Replace kmap() with kmap_local_page() Fabio M. De Francesco
2022-07-21 22:50 ` Ira Weiny
2022-07-31 1:58 ` Ira Weiny
2022-08-02 3:06 ` Baoquan He
2022-08-02 6:20 ` Fabio M. De Francesco
2022-08-02 7:32 ` Baoquan He
2022-08-02 11:02 ` Fabio M. De Francesco [this message]
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=5847084.alqRGMn8q6@opensuse \
--to=fmdefrancesco@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=ebiederm@xmission.com \
--cc=ira.weiny@intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox