All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 00/21] Lock extents before pages
Date: Thu,  2 Mar 2023 16:24:45 -0600	[thread overview]
Message-ID: <20230302222506.14955-1-rgoldwyn@suse.de> (raw)

The main idea is that instead of handling extent locks per page, lock
the extents before handling the pages. This will help in calling iomap
functions from within extent locks, so all page/folio handling is
performed by iomap code.

The patch "debug extent locking" was added to debug this code to check
where the locks were initiated in case of deadlock. No need to add
this patch.

Changes since v1:
 - qgroup flush reversal, instead pass nowait=true and handle
   qgroup flush if qgroup reservations return EDQUOT
 - relocation - locking extents before pages
 - async code locking fix: async code deadlocked because parallel
   writebacks could set HAS_ASYNC_EXTENTS flag while other thread was
   performing a sync writeback. This required re-writing the async writeback
   path
 - incorporated lock range checks using WARN_ON(), though I must
   admit locking during truncate still looks ugly
 - added readahead_begin() for locking extents before calling readahead()
   since readahead is called with pages locked.

Goldwyn Rodrigues (21):
  fs: readahead_begin() to call before locking folio
  btrfs: add WARN_ON() on incorrect lock range
  btrfs: Add start < end check in btrfs_debug_check_extent_io_range()
  btrfs: make btrfs_qgroup_flush() non-static
  btrfs: Lock extents before pages for buffered write()
  btrfs: wait ordered range before locking during truncate
  btrfs: lock extents while truncating
  btrfs: no need to lock extent while performing invalidate_folio()
  btrfs: lock extents before folio for read()s
  btrfs: lock extents before pages in writepages
  btrfs: locking extents for async writeback
  btrfs: lock extents before pages - defrag
  btrfs: Perform memory faults under locked extent
  btrfs: writepage fixup lock rearrangement
  btrfs: lock extent before pages for encoded read ioctls
  btrfs: lock extent before pages in encoded write
  btrfs: btree_writepages lock extents before pages
  btrfs: check if writeback pages exist before starting writeback
  btrfs: lock extents before pages in relocation
  btrfs: Add inode->i_count instead of calling ihold()
  btrfs: debug extent locking

 fs/btrfs/compression.c       |   9 +-
 fs/btrfs/defrag.c            |  48 +---
 fs/btrfs/disk-io.c           |  28 ++-
 fs/btrfs/extent-io-tree.c    |  32 +--
 fs/btrfs/extent-io-tree.h    |  46 ++--
 fs/btrfs/extent_io.c         |  74 +-----
 fs/btrfs/extent_io.h         |   2 +
 fs/btrfs/extent_map.c        |   2 +-
 fs/btrfs/file.c              | 100 +++-----
 fs/btrfs/free-space-cache.c  |   2 +-
 fs/btrfs/inode.c             | 431 ++++++++++++++++++-----------------
 fs/btrfs/ordered-data.c      |   8 +-
 fs/btrfs/ordered-data.h      |   3 +-
 fs/btrfs/qgroup.c            |   6 +-
 fs/btrfs/qgroup.h            |   1 +
 fs/btrfs/relocation.c        |  44 ++--
 include/linux/fs.h           |   1 +
 include/trace/events/btrfs.h |  18 +-
 mm/readahead.c               |   3 +
 19 files changed, 397 insertions(+), 461 deletions(-)

-- 
2.39.2



             reply	other threads:[~2023-03-02 22:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-02 22:24 Goldwyn Rodrigues [this message]
2023-03-09 18:10 ` [PATCH 00/21] Lock extents before pages David Sterba
2023-03-10  7:50   ` Christoph Hellwig
2023-03-10 16:38     ` Goldwyn Rodrigues
2023-03-13  9:16       ` Christoph Hellwig
2023-03-15 19:16     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230302222506.14955-1-rgoldwyn@suse.de \
    --to=rgoldwyn@suse.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.