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@xxxxxxxxxxxxx
