linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/8] xarray: Provide xas_erase() helper
Date: Sat, 14 Mar 2020 12:54:53 -0700	[thread overview]
Message-ID: <20200314195453.GS22433@bombadil.infradead.org> (raw)
In-Reply-To: <20200204142514.15826-3-jack@suse.cz>

On Tue, Feb 04, 2020 at 03:25:08PM +0100, Jan Kara wrote:
> Currently xas_store() clears marks when stored value is NULL. This is
> somewhat counter-intuitive and also causes measurable performance impact
> when mark clearing is not needed (e.g. because marks are already clear).
> So provide xas_erase() helper (similarly to existing xa_erase()) which
> stores NULL at given index and also takes care of clearing marks. Use
> this helper from __xa_erase() and item_kill_tree() in tools/testing.  In
> the following patches, callers that use the mark-clearing property of
> xas_store() will be converted to xas_erase() and remaining users can
> enjoy better performance.

I (finally!) figured out what I don't like about this series.  You're
changing the semantics of xas_store() without changing the name, so
if we have any new users in flight they'll use the new semantics when
they're expecting the old.

Further, while you've split the patches nicely for review, they're not
good for bisection because the semantic change comes right at the end
of the series, so any problem due to this series is going to bisect to
the end, and not tell us anything useful.

What I think this series should do instead is:

Patch 1:
+#define xas_store(xas, entry)	xas_erase(xas, entry)
-void *xas_store(struct xa_state *xas, void *entry)
+void *__xas_store(struct xa_state *xas, void *entry)
-	if (!entry)
-		xas_init_marks(xas);
+void *xas_erase(struct xa_state *xas, void *entry)
+{
+	xas_init_marks(xas);
+	return __xas_store(xas, entry);
+}
(also documentation changes)

Patches 2-n:
Change each user of xas_store() to either xas_erase() or __xas_store()

Patch n+1:
-#define xas_store(xas, entry)  xas_erase(xas, entry)

Does that make sense?  I'll code it up next week unless you want to.

  reply	other threads:[~2020-03-15  7:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 14:25 [PATCH 0/8] mm: Speedup page cache truncation Jan Kara
2020-02-04 14:25 ` [PATCH 1/8] xarray: Fix premature termination of xas_for_each_marked() Jan Kara
2020-03-12 21:45   ` Matthew Wilcox
2020-03-16  9:16     ` Jan Kara
2020-02-04 14:25 ` [PATCH 2/8] xarray: Provide xas_erase() helper Jan Kara
2020-03-14 19:54   ` Matthew Wilcox [this message]
2020-03-16  9:21     ` Jan Kara
2020-03-17 15:28   ` Matthew Wilcox
2020-04-15 16:12     ` Jan Kara
2020-02-04 14:25 ` [PATCH 3/8] xarray: Explicitely set XA_FREE_MARK in __xa_cmpxchg() Jan Kara
2020-02-05 18:45   ` Jason Gunthorpe
2020-02-06  8:03     ` Jan Kara
2020-03-17 15:12   ` Matthew Wilcox
2020-02-04 14:25 ` [PATCH 4/8] mm: Use xas_erase() in page_cache_delete_batch() Jan Kara
2020-02-04 14:25 ` [PATCH 5/8] dax: Use xas_erase() in __dax_invalidate_entry() Jan Kara
2020-02-04 14:25 ` [PATCH 6/8] idr: Use xas_erase() in ida_destroy() Jan Kara
2020-02-04 14:25 ` [PATCH 7/8] mm: Use xas_erase() in collapse_file() Jan Kara
2020-02-04 14:25 ` [PATCH 8/8] xarray: Don't clear marks in xas_store() Jan Kara
2020-02-05 18:43   ` Jason Gunthorpe
2020-02-05 21:59     ` Matthew Wilcox
2020-02-06 13:49       ` Jason Gunthorpe
2020-02-06 14:36         ` Jan Kara
2020-02-06 14:49           ` Jason Gunthorpe
2020-02-05 22:19   ` John Hubbard
2020-02-06  2:21     ` Matthew Wilcox
2020-02-06  3:48       ` John Hubbard
2020-02-06  4:28         ` Matthew Wilcox
2020-02-06  4:37           ` John Hubbard
2020-02-06  8:36           ` Jan Kara
2020-02-06  8:04     ` Jan Kara
2020-02-06 14:40 ` [PATCH 0/8] mm: Speedup page cache truncation David Sterba
2020-02-18  9:25 ` Jan Kara

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=20200314195453.GS22433@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.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).