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
