btrfs: support huge data folios for 4K page size

[REASON FOR RFC]

- Unstable baseline for-next branch
  The current for-next branch has a known regression where
  btrfs_async_reclaim_metadata_space() kworker can fall into a dead loop
  and fail several ENOSPC test cases.
  Although the regression is pinned down, I'm still waiting for a good
  baseline to rebase the series.

- Extra on-stack memory usage
  Currently we have two bitmaps that are using extra on-stack memory.
  Each of them uses 64 bytes on-stack memory, so in total we can have
  128 bytes just for the bitmaps.

  Not sure if it's a concern.

- Uncertainty related to v7.2 large folio support
  I'm planning to move large data folio support out of experimental.
  So when that support is no longer experimental, this huge folio support
  would need to start as experimental

  Depends on which patch(set) is merged first, there needs to be some
  modification to ensure end users won't suddenly get not only large but
  also huge folios.

Currently btrfs only supports folios as large as BITS_PER_LONG * blocks.
This is an artificial limit introduced to make bitmap operations easier.

Btrfs has two extra bitmaps that are out of btrfs_folio_state structure,
btrfs_bio_ctrl->submit_bitmap and @delalloc_bitmap inside
writepage_delalloc().

Limits the bitmap size to BITS_PER_LONG makes it very easy to handle the
above two bitmaps, we can just use a local unsigned long, no need to do
any memory allocation.

On the other hand, those two external bitmaps are the only thing
limiting huge folios.

The 1st patch will update the comments related to subpage implementation
first.
The 2nd patch will handle the subpage internal operations, mostly to
handle bitmap dumping.
The 3rd patch will prepare btrfs_bio_ctrl::submit_bitmap to be a proper
pointer for the incoming huge folios support.

The 4th patch will remove the 2K block size support, as it will double
the bitmap size for no obvious benefit, as it doesn't even improve the
coverage on 4K page sized systems anymore.

The final patch will enable the huge folio support, by using on-stack
bitmap that can contain 512 bits.
That will ensure 2MiB folio size, which is order 9 on 4K page sized
systems.

Qu Wenruo (5):
  btrfs: update the out-of-date comments on subpage
  btrfs: prepare subpage operations to support >= BITS_PER_LONG
    sub-bitmaps
  btrfs: migrate btrfs_bio_ctrl::submit_bitmap to support larger bitmaps
  btrfs: remove 2K block size support
  btrfs: introduce support for huge folios

 fs/btrfs/disk-io.c   |   2 +-
 fs/btrfs/extent_io.c |  73 +++++++++------
 fs/btrfs/fs.h        |  16 ++--
 fs/btrfs/subpage.c   | 209 +++++++++++++++++++++++++------------------
 fs/btrfs/subpage.h   |   8 +-
 5 files changed, 176 insertions(+), 132 deletions(-)

-- 
2.53.0