All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: xfs <linux-xfs@vger.kernel.org>
Cc: Dave Chinner <david@fromorbit.com>,
	Brian Foster <bfoster@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	Allison Henderson <allison.henderson@oracle.com>,
	Chandan Babu R <chandanrlinux@gmail.com>
Subject: patch review scheduling...
Date: Tue, 25 May 2021 18:27:04 -0700	[thread overview]
Message-ID: <20210526012704.GH202144@locust> (raw)

Hello list, frequent-submitters, and usual-reviewer-suspects:

As you've all seen, we have quite a backlog of patch review for 5.14
already.  The people cc'd on this message are the ones who either (a)
authored the patches caught in the backlog, (b) commented on previous
iterations of them, or (c) have participated in a lot of reviews before.

Normally I'd just chug through them all until I get to the end, but even
after speed-reading through the shorter series (deferred xattrs,
mmaplock, reflink+dax) I still have 73 to go, which is down from 109
this morning.

So, time to be a bit more aggressive about planning.  I would love it if
people dedicated some time this week to reviewing things, but before we
even get there, I have other questions:

Dave: Between the CIL improvements and the perag refactoring, which
would you rather get reviewed first?  The CIL improvments patches have
been circulating longer, but they're more subtle changes.

Dave and Christoph: Can I rely on you both to sort out whatever
conflicts arose around reworking memory page allocation for xfs_bufs?

Brian: Is it worth the time to iterate more on the ioend thresholds in
the "iomap: avoid soft lockup warnings" series?  Specifically, I was
kind of interested in whether or not we should/could scale the max ioend
size limit with the optimal/max io request size that devices report,
though I'm getting a feeling that block device limits are all over the
place maybe we should start with the static limit and iterate up (or
down?) from there...?

Everyone else: If you'd like to review something, please stake a claim
and start reading.

Everyone else not on cc: You're included too!  If you like! :)

--D

             reply	other threads:[~2021-05-26  1:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26  1:27 Darrick J. Wong [this message]
2021-05-26  2:01 ` patch review scheduling Dave Chinner
2021-05-26 11:53 ` Brian Foster
2021-05-26 18:26   ` Darrick J. Wong

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=20210526012704.GH202144@locust \
    --to=djwong@kernel.org \
    --cc=allison.henderson@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=chandanrlinux@gmail.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.