Re: [PATCH 0/3] btrfs: Replace kmap() with kmap_local_page()

From: Ira Weiny <ira.weiny@intel.com>
To: David Sterba <dsterba@suse.cz>
Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH 0/3] btrfs: Replace kmap() with kmap_local_page()
Date: Thu, 2 Jun 2022 09:22:15 -0700	[thread overview]
Message-ID: <Ypjjt87qL+ROFBtM@iweiny-desk3> (raw)
In-Reply-To: <20220601132545.GM20633@twin.jikos.cz>

On Wed, Jun 01, 2022 at 03:25:45PM +0200, David Sterba wrote:
> On Tue, May 31, 2022 at 04:53:32PM +0200, Fabio M. De Francesco wrote:
> > This is the first series of patches aimed towards the conversion of Btrfs
> > filesystem from the use of kmap() to kmap_local_page().
> 
> We've already had patches converting kmaps and you're changing the last
> ones, so this is could be the last series, with two exceptions.
> 
> 1) You've changed lzo.c and zlib. but the same kmap/kunmap pattern is
>    used in zstd.c.

I checked out zstd.c and one of the issues there is the way that the input
workspace is mapped page by page while iterating those pages.

This got me thinking about what Willy said at LSFmm concerning something like
kmap_local_range().  Mapping more than 1 page at a time could save some
unmap/remap of output pages required for kmap_local_page() ordering.

Unfortunately, I think the length of the input is probably to long in many
cases.  And some remapping may still be required.

Cc: Willy

As an aside, Willy, I'm thinking that a kmap_local_range() should return a
folio in some way.  Would you agree?

Ira