Re: [5.19 cycle] Planning and goals

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

On Tue, Apr 05, 2022 at 12:03:12PM +1000, Dave Chinner wrote:
> Hi folks,
> 
> I'd really like to try getting the merge bottlenecks we've had
> recently unstuck, so there are a few patchsets I want to try to get
> reviewed, tested and merged for 5.19. Hopefully not too many
> surprises will get in the way and so some planning to try to
> minimises surprised might be a good thing.  Hence I want to have a
> rough plan for the work I'd like to acheive during this 5.19 cycle,
> and so that everyone has an idea of what needs to be done to (maybe)
> achieve those goals over the next few weeks.
> 
> First of all, a rough timeline that I'm working with:
> 
> 5.18-rc1:	where we are now
> 5.18-rc2:	Update linux-xfs master branch to 5.19-rc2

Presumably you meant 5.18-rc2 here?

> 5.18-rc4:	At least 2 of the major pending works merged
> 5.18-rc6:	Last point for new work to be merged
> 5.18-rc6+:	Bug fixes only will be merged 
> 
> I'm assuming a -rc7 kernel will be released, hence this rough
> timeline gives us 2 weeks of testing/stabilisation time before 5.19
> merge window opens. 
> 
> Patchsets for review should be based on either 5.17.0 or the
> linux-xfs master branch once it has been updated to 5.19-rc2. If

...and here?

> there are important bug fixes for the 5.18 cycle, I may move the
> master branch forwards to a more recent release.
>
> In terms of merge process, I plan to keep each major set of work in
> a separate topic branch so that once it has been merged the commit
> IDs remain stable. I will then merge the topic branches into the
> for-next branch. Hence the for-next tree may still rebase (e.g. if I
> need to send fixes for 5.18-rcX), but I hope to keep the individual
> commits that make up the for-next branch as stable as possible. Bug
> fixes for patchsets will get appended to the topic branches and the
> for-next branch rebuilt via a new set of merges.

Hmm, that's a way to do it that I hadn't previously considered.

> The major patchsets that I'm hoping to get reviewed and merged this
> cycle:
> 
> - large extent counts V8 (Chandan)
> 	- Merge criteria and status:
> 		- review complete: 95%
> 		- no regressions when not enabled: 70%
> 		- no major regressions when enabled: 0%
> 	- Open questions:
> 		- Experimental tag for the first couple of cycles?
> 		  (Darrick says "YES" on #xfs)
> 	- Needs more QA, but signs are good so far.
> 	- Almost ready to merge.

I think this one is mostly ready to go, with the few nits fixed that you
and I have already posted about.

> - Logged attributes V28 (Allison)
> 	- I haven't looked at this since V24, so I'm not sure what
> 	  the current status is. I will do that discovery later in
> 	  the week.
> 	- Merge criteria and status:
> 		- review complete: Not sure
> 		- no regressions when not enabled: v24 was OK
> 		- no major regressions when enabled: v24 had issues
> 	- Open questions:
> 		- not sure what review will uncover
> 		- don't know what problems testing will show
> 		- what other log fixes does it depend on?
> 		- is there a performance impact when not enabled?

Hm.  Last time I went through this I was mostly satisfied except for (a)
all of the subtle rules about who owns and frees the attr name/value
buffers, and (b) all that stuff with the alignment/sizing asserts
tripping on fsstress loop tests.

I /think/ Allison's fixed (a), and I think Dave had a patch or two for
(b)?

Oh one more thing:

ISTR one of the problems is that the VFS allocates an onstack
buffer for the xattr name.  The buffer is char[], so the start of it
isn't necessarily aligned to what the logging code wants; and the end of
it (since it's 255 bytes long) almost assuredly isn't.

> - DAX + reflink V11 (Ruan)
> 	- Merge criteria and status:
> 		- review complete: 75%
> 		- no regressions when not enabled: unknown
> 		- no major regressions when enabled: unknown
> 	- Open questions:
> 		- still a little bit of change around change
> 		  notification?
> 		- Not sure when V12 will arrive, hence can't really
> 		  plan for this right now.
> 		- external dependencies?

I thought the XFS part of this patchset looked like it was in good
enough shape to merge, but the actual infrastructure stuff (AKA messing
with mm/ and dax code) hasn't gotten a review.  I don't really have the
depth to know if the changes proposed are good or bad.

> - xlog_write() rework V8
> 	- Merge criteria and status:
> 		- review complete: 100%
> 		- No regressions in testing: 100%
> 	- Open questions:
> 		- unchanged since last review/merge attempt,
> 		  reverted because of problems with other code that
> 		  was merged with it that isn't in this patchset
> 		  now. Does it need re-reviewing?

I suggest you rebase to something recent (5.17.0 + xfs-5.18-merge-4?)
and send it to the list for a quick once-over before merging that.
IIRC I understood it well enough to have been ok with putting it in.

That said, if you push a branch somewhere I'll give it a spin on my
testfrastructure to see if anything else falls off.

> 	- Ready to merge.
> 
> - Intent Whiteouts V3
> 	- Merge criteria and status:
> 		- review complete: 0%
> 		- No regressions in testing: 100%
> 	- Open questions:
> 		- will it get reviewed in time?
> 		- what bits of the patchset does LARP depend on?
> 		- Is LARP perf without intent whiteouts acceptible
> 		  (Experimental tag tends to suggest yes).
> 	- Functionally complete and tested, just needs review.

<shrug> No opinions, having never seen this before(?)

> Have I missed any of the major outstanding things that are nearly
> ready to go?

At this point my rmap/reflink performance speedups series are ready for
review, but I think the xlog and nrext64 are more than enough for a
single cycle.

> Do the patchset authors have the time available in the next 2-3
> weeks to make enough progress to get their work merged? I'd kinda
> like to have the xlog_write() rework and the large extent counts
> merged ASAP so we have plenty of time to focus on the more
> complex/difficult pieces.  If you don't have time in the next few
> weeks, then let me know so I can adjust the plan appropriately for
> the cycle.
> 
> What does everyone think of the plan?

I like that you're making the plan explicit.  I'd wanted to talk about
doing this back at LPC 2021, but nobody from RH registered... :(

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com