On Fri, May 14, 2021 at 01:30:40PM +0200, David Sterba wrote:

On Thu, May 13, 2021 at 10:21:24AM +0800, Qu Wenruo wrote:

quoted

quoted

On 2021/5/13 上午6:18, David Sterba wrote:

quoted

On Wed, Apr 28, 2021 at 07:03:07AM +0800, Qu Wenruo wrote:

quoted

=== Patchset structure ===

Patch 01~02:    hardcoded PAGE_SIZE related fixes
Patch 03~05:    submit_extent_page() refactor which will reduce overhead
        for write path.
        This should benefit 4K page the most. Although the
        primary objective is just to make the code easier to
        read.
Patch 06:    Cleanup for metadata writepath, to reduce the impact on
        regular sectorsize path.
Patch 07~13:    PagePrivate2 and ordered extent related refactor.
        Although it's still a refactor, the refactor is pretty
        important for subpage data write path, as for subpage we
        could have btrfs_writepage_endio_finish_ordered() call
        across several sectors, which may or may not have
        ordered extent for those sectors.

^^^ Above patches are all subpage data write preparation ^^^

Do you think the patches 1-13 are safe to be merged independently? I've
paged through the whole patchset and some of the patches are obviously
preparatory stuff so they can go in without much risk.

Yes. I believe they are OK for merge.

I have run the full tests on x86 VM for the whole patchset, no new
regression.

Especially patch 03~05 would benefit 4K page size the most, thus merging
them first would definitely help.

Just let me to run the tests with patch 1~13 only, to see if there is
any special dependency missing.

Yep, patch 1~13 with the v5 read time repair patches are safe for x86.

All fine up to generic/521 that got stuck. It looks like some use after
free, check the 2nd line of the dump, there's the 0x6b6b signature

On the same VM it did not appear for 2-3 runs, but now I see it on a
different one, so it's not deterministic. The error is the same.