Re: patch review scheduling...

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, May 26, 2021 at 07:53:11AM -0400, Brian Foster wrote:
> On Tue, May 25, 2021 at 06:27:04PM -0700, Darrick J. Wong wrote:
> > 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...?
> > 
> 
> I was starting to think about the optimal I/O size thing yesterday given
> the latest feedback. I think it makes sense and it's probably easy
> enough to incorporate, but if you're asking me about patch processing
> logistics, IMO none of the changes or outstanding feedback since the v2
> (inline w/ v1) are terribly important to fix the original problem.
> 
> Most of the feedback since v2 has been additive (i.e. "fix this problem
> too") or surmising about inconsequential things like cond_resched()
> usage or whether the threshold should be defined based on pages or not.
> v2 used a large threshold to avoid things like risk of
> unintended/unexpected consequences causing a revert down the line and
> reintroducing the soft lockup problem, which is otherwise easily fixable
> without significant change to functional behavior (given the current
> worst case of unbound aggregation). So since you ask and after having
> thought about it, if you're looking for a targeted fix to merge sooner
> rather than later I think the smart thing to do is stick with v2 and
> rebase the subsequent changes to reduce interrupt context latency and
> general completion latency on top of that. (In fact, I probably should
> have done that for v3.)

Yeah, this basically comes down to: take v2 as a fix for 5.13?  Or v3
as a larger fix for 5.14?  I guess I'm the one ranting about having too
many stall warning escalations, so it's up to me to pick something.
TBH I like the "put v3 in 5.14" option since it gives us a much longer
testing ramp...

--D

> 
> Brian
> 
> > 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
> > 
>