Hi Ira, On Tue, Oct 18, 2022 at 07:51:55PM -0700, Ira Weiny wrote: > 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?
... mainly due to map/unmap ordering restriction. I think the decompressor here could still be a simple dependency. I'm not sure if there are more complicated cases (like multiple decoding/encoding sources into target pages) though.. Thanks, Gao Xiang > > Ira
