linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: ira.weiny@intel.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/4] btrfs: Convert kmaps to core page calls
Date: Tue, 9 Feb 2021 16:11:23 +0100	[thread overview]
Message-ID: <20210209151123.GT1993@suse.cz> (raw)
In-Reply-To: <20210205232304.1670522-1-ira.weiny@intel.com>

On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
> 
> There are many places where kmap/<operation>/kunmap patterns occur.  We lift
> these various patterns to core common functions and use them 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.
> 
> I think this is best accepted through Andrew's tree as it has the mem*_page
> functions in it.  But I'd like to get an ack from David or one of the other
> btrfs maintainers before the btrfs patches go through.

I'd rather take the non-mm patches through my tree so it gets tested
the same way as other btrfs changes, straightforward cleanups or not.

This brings the question how to do that as the first patch should go
through the MM tree. One option is to posptpone the actual cleanups
after the 1st patch is merged but this could take a long delay.

I'd suggest to take the 1st patch within MM tree in the upcoming merge
window and then I can prepare a separate pull with just the cleanups.
Removing an inter-tree patch dependency was a sufficient reason for
Linus in the past for such pull requests.

> There are a lot more kmap->kmap_local_page() conversions but kmap_local_page()
> requires some care with the unmapping order and so I'm still reviewing those
> changes because btrfs uses a lot of loops for it's kmaps.

It sounds to me that converting the kmaps will take some time anyway so
exporting the helpers first and then converting the subsystems might be
a good option. In case you'd like to get rid of the simple cases in
btrfs code now we can do the 2 pull requests.

  parent reply	other threads:[~2021-02-09 15:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 23:23 [PATCH 0/4] btrfs: Convert kmaps to core page calls ira.weiny
2021-02-05 23:23 ` [PATCH 1/4] mm/highmem: Lift memcpy_[to|from]_page to core ira.weiny
2021-02-07  1:46   ` Chaitanya Kulkarni
2021-02-08  3:13     ` Ira Weiny
2021-02-08  4:34       ` Chaitanya Kulkarni
2021-02-05 23:23 ` [PATCH 2/4] fs/btrfs: Use memcpy_[to|from]_page() ira.weiny
2021-02-09 15:14   ` David Sterba
2021-02-05 23:23 ` [PATCH 3/4] fs/btrfs: Use copy_highpage() instead of 2 kmaps() ira.weiny
2021-02-05 23:23 ` [PATCH 4/4] fs/btrfs: Convert to zero_user() ira.weiny
2021-02-09 15:11 ` David Sterba [this message]
2021-02-09 17:45   ` [PATCH 0/4] btrfs: Convert kmaps to core page calls Ira Weiny
2021-02-09 19:09   ` Andrew Morton
2021-02-09 20:52     ` Ira Weiny
2021-02-09 21:11       ` Andrew Morton
2021-02-09 21:52         ` Ira Weiny
2021-02-09 21:58           ` Andrew Morton
2021-02-09 22:03             ` Ira Weiny
2021-02-09 22:27               ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210209151123.GT1993@suse.cz \
    --to=dsterba@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ira.weiny@intel.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).