From: Ira Weiny <ira.weiny@intel.com>
To: dsterba@suse.cz, 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 09:45:51 -0800 [thread overview]
Message-ID: <20210209174551.GA2975576@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20210209151123.GT1993@suse.cz>
On Tue, Feb 09, 2021 at 04:11:23PM +0100, David Sterba wrote:
> 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.
True.
>
> 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 others how want this base patch too.[1] So I like this option.
>
> > 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.
I would really like to get the simple case out of the way because the next
series has more difficult changes and the simple cases always cause me trouble
when grepping/coccinelle'ing for things.
So I would like a follow on pull request if possible. But I'm willing to do
what works best for you.
For now I will spin a new version with the changes you've requested ASAP.
Ira
[1] https://lore.kernel.org/linux-f2fs-devel/20210207190425.38107-1-chaitanya.kulkarni@wdc.com/
next prev parent reply other threads:[~2021-02-09 18:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 23:23 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 ` [PATCH 0/4] btrfs: Convert kmaps to core page calls David Sterba
2021-02-09 17:45 ` Ira Weiny [this message]
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=20210209174551.GA2975576@iweiny-DESK2.sc.intel.com \
--to=ira.weiny@intel.com \
--cc=akpm@linux-foundation.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--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
all inboxes | Powered by JetHome®