From: Ira Weiny <ira.weiny@intel.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: linux-erofs@lists.ozlabs.org,
"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] erofs: use kmap_local_page() only for erofs_bread()
Date: Tue, 18 Oct 2022 19:51:55 -0700 [thread overview]
Message-ID: <Y09mS6LrHCGmi+AJ@iweiny-desk3> (raw)
In-Reply-To: <Y084l0m88JGOqGRN@B-P7TQMD6M-0146.lan>
On Wed, Oct 19, 2022 at 07:36:55AM +0800, Gao Xiang wrote:
> On Wed, Oct 19, 2022 at 01:21:27AM +0200, Fabio M. De Francesco wrote:
> > On Tuesday, October 18, 2022 11:29:21 PM CEST Gao Xiang wrote:
>
> ...
[snip]
> >
> > In Btrfs I solved (thanks to David S.' advice) by mapping only one of two
> > pages, only the one coming from the page cache.
> >
> > The other page didn't need the use of kmap_local_page() because it was
> > allocated in the filesystem with "alloc_page(GFP_NOFS)". GFP_NOFS won't ever
> > allocate from ZONE_HIGHMEM, therefore a direct page_address() could avoid the
> > mapping and the nesting issues.
> >
> > Did you check if you may solve the same way?
>
> That is not simple. Currently we have compressed pages and decompressed
> pages (page cache or others), and they can be unmapped when either data
> is all consumed, so compressed pages can be unmapped first, or
> decompressed pages can be unmapped first. That quite depends on which
> pages goes first.
>
> I think such usage is a quite common pattern for decoder or encoder,
> you could take a look at z_erofs_lzma_decompress() in
> fs/erofs/decompressor_lzma.c. So kmap() is still useful for such cases
> since I don't really care the HIGHMEM performance but correctness, but
> other alternative could churn/complex the map/unmap/remap pattern.
>
When you say kmap() is still useful is this because of the map/unmap ordering
restrictions or because the address is required in different threads?
Ira
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
<linux-erofs@lists.ozlabs.org>, Chao Yu <chao@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] erofs: use kmap_local_page() only for erofs_bread()
Date: Tue, 18 Oct 2022 19:51:55 -0700 [thread overview]
Message-ID: <Y09mS6LrHCGmi+AJ@iweiny-desk3> (raw)
In-Reply-To: <Y084l0m88JGOqGRN@B-P7TQMD6M-0146.lan>
On Wed, Oct 19, 2022 at 07:36:55AM +0800, Gao Xiang wrote:
> On Wed, Oct 19, 2022 at 01:21:27AM +0200, Fabio M. De Francesco wrote:
> > On Tuesday, October 18, 2022 11:29:21 PM CEST Gao Xiang wrote:
>
> ...
[snip]
> >
> > In Btrfs I solved (thanks to David S.' advice) by mapping only one of two
> > pages, only the one coming from the page cache.
> >
> > The other page didn't need the use of kmap_local_page() because it was
> > allocated in the filesystem with "alloc_page(GFP_NOFS)". GFP_NOFS won't ever
> > allocate from ZONE_HIGHMEM, therefore a direct page_address() could avoid the
> > mapping and the nesting issues.
> >
> > Did you check if you may solve the same way?
>
> That is not simple. Currently we have compressed pages and decompressed
> pages (page cache or others), and they can be unmapped when either data
> is all consumed, so compressed pages can be unmapped first, or
> decompressed pages can be unmapped first. That quite depends on which
> pages goes first.
>
> I think such usage is a quite common pattern for decoder or encoder,
> you could take a look at z_erofs_lzma_decompress() in
> fs/erofs/decompressor_lzma.c. So kmap() is still useful for such cases
> since I don't really care the HIGHMEM performance but correctness, but
> other alternative could churn/complex the map/unmap/remap pattern.
>
When you say kmap() is still useful is this because of the map/unmap ordering
restrictions or because the address is required in different threads?
Ira
next prev parent reply other threads:[~2022-10-19 2:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 10:53 [PATCH v2] erofs: use kmap_local_page() only for erofs_bread() Gao Xiang
2022-10-18 16:28 ` Fabio M. De Francesco
2022-10-18 19:18 ` Fabio M. De Francesco
2022-10-18 19:18 ` Fabio M. De Francesco
2022-10-18 21:29 ` Gao Xiang
2022-10-18 21:29 ` Gao Xiang
2022-10-18 23:21 ` Fabio M. De Francesco
2022-10-18 23:21 ` Fabio M. De Francesco
2022-10-18 23:36 ` Gao Xiang
2022-10-18 23:36 ` Gao Xiang
2022-10-19 2:51 ` Ira Weiny [this message]
2022-10-19 2:51 ` Ira Weiny
2022-10-19 3:06 ` Gao Xiang
2022-10-19 3:06 ` Gao Xiang
2022-10-19 18:17 ` Fabio M. De Francesco
2022-10-19 18:17 ` Fabio M. De Francesco
2022-10-20 2:18 ` Gao Xiang
2022-10-20 2:18 ` Gao Xiang
2022-10-20 3:17 ` Ira Weiny
2022-10-20 3:17 ` Ira Weiny
2022-10-20 3:50 ` Gao Xiang
2022-10-20 3:50 ` Gao Xiang
2022-12-01 10:09 ` Jingbo Xu
2022-12-07 1:16 ` Chao Yu
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=Y09mS6LrHCGmi+AJ@iweiny-desk3 \
--to=ira.weiny@intel.com \
--cc=fmdefrancesco@gmail.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.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 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.