[V2,0/8] btrfs: convert kmaps to core page calls
mbox series

Message ID 20210210062221.3023586-1-ira.weiny@intel.com
Headers show
Series
  • btrfs: convert kmaps to core page calls
Related show

Message

Ira Weiny Feb. 10, 2021, 6:22 a.m. UTC
From: Ira Weiny <ira.weiny@intel.com>

Changes from V1:
	Rework commit messages because they were very weak
	Change 'fs/btrfs: X' to 'btrfs: x'
		https://lore.kernel.org/lkml/20210209151442.GU1993@suse.cz/
	Per Andrew
		Split out changes to highmem.h
			The addition memcpy, memmove, and memset page functions
			The change from kmap_atomic to kmap_local_page
			The addition of BUG_ON
			The conversion of memzero_page to zero_user in iov_iter
		Change BUG_ON to VM_BUG_ON
	While we are refactoring adjust the line length down per Chaitany


There are many places where kmap/<operation>/kunmap patterns occur.  We lift a
couple of these patterns to the core common functions and use them as well as
existing core functions in the btrfs file system.  At the same time we convert
those core functions to use kmap_local_page() which is more efficient in those
calls.

Per the conversation on V1 it looks like Andrew would like this to go through
the btrfs tree.  I think that is fine.  The other users of
memcpy_[to|from]_page are probably not ready and I believe could be taken in an
early rc after David submits.

Is that ok with you David?

Thanks,
Ira

Ira Weiny (8):
  mm/highmem: Lift memcpy_[to|from]_page to core
  mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page()
  mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page()
  mm/highmem: Add VM_BUG_ON() to mem*_page() calls
  iov_iter: Remove memzero_page() in favor of zero_user()
  btrfs: use memcpy_[to|from]_page() and kmap_local_page()
  btrfs: use copy_highpage() instead of 2 kmaps()
  btrfs: convert to zero_user()

 fs/btrfs/compression.c  | 11 +++-----
 fs/btrfs/extent_io.c    | 22 +++-------------
 fs/btrfs/inode.c        | 33 ++++++++----------------
 fs/btrfs/lzo.c          |  4 +--
 fs/btrfs/raid56.c       | 10 +-------
 fs/btrfs/reflink.c      | 12 ++-------
 fs/btrfs/send.c         |  7 ++----
 fs/btrfs/zlib.c         | 10 +++-----
 fs/btrfs/zstd.c         | 11 +++-----
 include/linux/highmem.h | 56 +++++++++++++++++++++++++++++++++++++++++
 lib/iov_iter.c          | 26 +++----------------
 11 files changed, 89 insertions(+), 113 deletions(-)

Comments

David Sterba Feb. 11, 2021, 7:38 p.m. UTC | #1
On Tue, Feb 09, 2021 at 10:22:13PM -0800, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
> 
> Changes from V1:
> 	Rework commit messages because they were very weak
> 	Change 'fs/btrfs: X' to 'btrfs: x'
> 		https://lore.kernel.org/lkml/20210209151442.GU1993@suse.cz/
> 	Per Andrew
> 		Split out changes to highmem.h
> 			The addition memcpy, memmove, and memset page functions
> 			The change from kmap_atomic to kmap_local_page
> 			The addition of BUG_ON
> 			The conversion of memzero_page to zero_user in iov_iter
> 		Change BUG_ON to VM_BUG_ON
> 	While we are refactoring adjust the line length down per Chaitany
> 
> 
> There are many places where kmap/<operation>/kunmap patterns occur.  We lift a
> couple of these patterns to the core common functions and use them as well as
> existing core functions in the btrfs file system.  At the same time we convert
> those core functions to use kmap_local_page() which is more efficient in those
> calls.
> 
> Per the conversation on V1 it looks like Andrew would like this to go through
> the btrfs tree.  I think that is fine.  The other users of
> memcpy_[to|from]_page are probably not ready and I believe could be taken in an
> early rc after David submits.
> 
> Is that ok with you David?

Yes.

The branch is now in
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/log/?h=kmap-conversion
let me know if I've missed acked-by or reviewed-by, I added those sent
to the mailinglist and added mine to the btrfs ones and to the iov_iter
patch.

I'll add the patchset to my for-next so it gets picked by linux-next and
will keep testing it for at least a week.

Though this is less than the expected time before merge window, the
reasoning is that it's exporting helpers that are going to be used in
various subsystems. The changes in btrfs are simple and would allow to
focus on the other less trivial conversions. ETA for the pull request is
mid of the 2nd week of the merge window or after rc1.
Ira Weiny Feb. 11, 2021, 9:32 p.m. UTC | #2
On Thu, Feb 11, 2021 at 08:38:03PM +0100, David Sterba wrote:
> On Tue, Feb 09, 2021 at 10:22:13PM -0800, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > Per the conversation on V1 it looks like Andrew would like this to go through
> > the btrfs tree.  I think that is fine.  The other users of
> > memcpy_[to|from]_page are probably not ready and I believe could be taken in an
> > early rc after David submits.
> > 
> > Is that ok with you David?
> 
> Yes.
> 
> The branch is now in
> https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/log/?h=kmap-conversion
> let me know if I've missed acked-by or reviewed-by, I added those sent
> to the mailinglist and added mine to the btrfs ones and to the iov_iter
> patch.

Looks good.  Thank you!

> 
> I'll add the patchset to my for-next so it gets picked by linux-next and
> will keep testing it for at least a week.
> 
> Though this is less than the expected time before merge window, the
> reasoning is that it's exporting helpers that are going to be used in
> various subsystems. The changes in btrfs are simple and would allow to
> focus on the other less trivial conversions. ETA for the pull request is
> mid of the 2nd week of the merge window or after rc1.

Thanks for working with me on this.  Yes these were the more straight forward
conversions.  The next set will require more review and I should have them
posted soon at least for RFC.  Unfortunately, there are 2 places which are
proving difficult to follow the mapping orders required of kmap_local_page().
I'll open that discussion with the next round of conversions.

For now, thank you again,
Ira