Messages in this thread | | | Date | Wed, 19 Oct 2022 05:29:21 +0800 | From | Gao Xiang <> | Subject | Re: [PATCH v2] erofs: use kmap_local_page() only for erofs_bread() |
| |
Hi Fabio,
On Tue, Oct 18, 2022 at 09:18:49PM +0200, Fabio M. De Francesco wrote: > On Tuesday, October 18, 2022 12:53:13 PM CEST Gao Xiang wrote: > > Convert all mapped erofs_bread() users to use kmap_local_page() > > instead of kmap() or kmap_atomic(). > > > > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> > > --- > > fs/erofs/data.c | 8 ++------ > > fs/erofs/internal.h | 3 +-- > > fs/erofs/xattr.c | 8 ++++---- > > fs/erofs/zmap.c | 4 ++-- > > 4 files changed, 9 insertions(+), 14 deletions(-) > > > > I just realized that you know the code of fs/erofs very well. I saw a Gao > Xiang in MAINTAINERS, although having a different email address. > > Therefore, I'm sure that everybody can trust that you checked everything is > needed to assure the safety of the conversions. > > However, an extended commit message would have prevented me to send you the > previous email with all those questions / objections.
Thanks for your suggestion. Yeah, this conversion looks trivial [since most paths for erofs_bread() don't have more restriction in principle so we can just disable migration. One of what I need to care is nested kmap() usage, some unmap/remap order cannot be simply converted to kmap_local() but I think it's not the case for erofs_bread(). Actually EROFS has one of such nested kmap() usage, but I don't really care its performance on HIGHMEM platforms, so I think kmap() is still somewhat useful compared to kmap_local() from this point of view], but in order to make it all work properly, I will try to do stress test with 32-bit platform later. Since it targets for the next cycle 6.2, I will do a full stress test in the next following weeks.
Thanks, Gao Xiang
> > Thanks, > > Fabio >
| |