From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Evgeniy Dushistov <dushistov@mail.ru>,
bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Ira Weiny <ira.weiny@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/3] fs/ufs: replace kmap() with kmap_local_page
Date: Wed, 21 Dec 2022 18:46:08 +0100 [thread overview]
Message-ID: <8213044.NyiUUSuA9g@suse> (raw)
In-Reply-To: <20221217184749.968-1-fmdefrancesco@gmail.com>
On sabato 17 dicembre 2022 19:47:46 CET Fabio M. De Francesco wrote:
> kmap() is being deprecated in favor of kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead as
> the 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.
>
> With kmap_local_page() the mappings are per thread, CPU local, can take
> page faults, and can be called from any context (including interrupts).
> It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
> the tasks can be preempted and, when they are scheduled to run again, the
> kernel virtual addresses are restored and still valid.
>
> Since its use in fs/ufs is safe everywhere, it should be preferred.
>
> Therefore, replace kmap() with kmap_local_page() in fs/ufs. kunmap_local()
> requires the mapping address, so return that address from ufs_get_page()
> to be used in ufs_put_page().
>
> This series could have not been ever made because nothing prevented the
> previous patch from working properly but Al Viro made a long series of
> very appreciated comments about how many unnecessary and redundant lines
> of code I could have removed. He could see things I was entirely unable
> to notice. Furthermore, he also provided solutions and details about how
> I could decompose a single patch into a small series of three
> independent units.[1][2][3]
>
> I want to thank him so much for the patience, kindness and the time he
> decided to spend to provide those analysis and write three messages full
> of interesting insights.[1][2][3]
>
> Changes from v1:
> 1/3: No changes.
> 2/3: Restore the return of "err" that was mistakenly deleted
> together with the removal of the "out" label in
> ufs_add_link(). Thanks to Al Viro.[4]
> Return the address of the kmap()'ed page instead of a
> pointer to a pointer to the mapped page; a page_address()
> had been overlooked in ufs_get_page(). Thanks to Al
> Viro.[5]
> 3/3: Return the kernel virtual address got from the call to
> kmap_local_page() after conversion from kmap(). Again
> thanks to Al Viro.[6]
>
> Changes from v2:
> 1/3: No changes.
> 2/3: Rework ufs_get_page() because the previous version had two
> errors: (1) It could return an invalid pages with the out
> argument "page" and (2) it could return "page_address(page)"
> also in cases where read_mapping_page() returned an error
> and the page is never kmap()'ed. Thanks to Al Viro.[7]
> 3/3: Rework ufs_get_page() after conversion to
> kmap_local_page(), in accordance to the last changes in 2/3.
>
> [1] https://lore.kernel.org/lkml/Y4E++JERgUMoqfjG@ZenIV/
> [2] https://lore.kernel.org/lkml/Y4FG0O7VWTTng5yh@ZenIV/
> [3] https://lore.kernel.org/lkml/Y4ONIFJatIGsVNpf@ZenIV/
> [4] https://lore.kernel.org/lkml/Y5Zc0qZ3+zsI74OZ@ZenIV/
> [5] https://lore.kernel.org/lkml/Y5ZZy23FFAnQDR3C@ZenIV/
> [6] https://lore.kernel.org/lkml/Y5ZcMPzPG9h6C9eh@ZenIV/
> [7] https://lore.kernel.org/lkml/Y5glgpD7fFifC4Fi@ZenIV/#t
>
> The cover letter of the v1 series is at
> https://lore.kernel.org/lkml/20221211213111.30085-1-fmdefrancesco@gmail.com/
> The cover letter of the v2 series is at
> https://lore.kernel.org/lkml/20221212231906.19424-1-fmdefrancesco@gmail.com/
>
> Fabio M. De Francesco (3):
> fs/ufs: Use the offset_in_page() helper
> fs/ufs: Change the signature of ufs_get_page()
> fs/ufs: Replace kmap() with kmap_local_page()
>
> fs/ufs/dir.c | 134 +++++++++++++++++++++++++++------------------------
> 1 file changed, 71 insertions(+), 63 deletions(-)
>
> --
> 2.39.0
Please drop this v3 because of a mistake in patch 3/3.
The updated v4 series is at
https://lore.kernel.org/lkml/20221221172802.18743-1-fmdefrancesco@gmail.com/T/
Thanks,
Fabio
prev parent reply other threads:[~2022-12-21 17:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 18:47 [PATCH v3 0/3] fs/ufs: replace kmap() with kmap_local_page Fabio M. De Francesco
2022-12-17 18:47 ` [PATCH v3 1/3] fs/ufs: Use the offset_in_page() helper Fabio M. De Francesco
2022-12-17 18:47 ` [PATCH v3 2/3] fs/ufs: Change the signature of ufs_get_page() Fabio M. De Francesco
2022-12-17 18:47 ` [PATCH v3 3/3] fs/ufs: Replace kmap() with kmap_local_page() Fabio M. De Francesco
2022-12-19 17:50 ` Fabio M. De Francesco
2022-12-21 17:46 ` 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=8213044.NyiUUSuA9g@suse \
--to=fmdefrancesco@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=dushistov@mail.ru \
--cc=ira.weiny@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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