linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joanne Koong <joannelkoong@gmail.com>
To: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org
Cc: josef@toxicpanda.com, bernd.schubert@fastmail.fm,
	jefflexu@linux.alibaba.com, hannes@cmpxchg.org,
	shakeel.butt@linux.dev, linux-mm@kvack.org, kernel-team@meta.com
Subject: [PATCH 0/2] fuse: remove extra page copies in writeback
Date: Fri, 11 Oct 2024 15:34:32 -0700	[thread overview]
Message-ID: <20241011223434.1307300-1-joannelkoong@gmail.com> (raw)

Currently when we handle writeback in fuse, we allocate and copy data
to a temporary folio in order to mitigate the following deadlock scenario
that may arise if reclaim waits on writeback to complete:
* single-threaded FUSE server is in the middle of handling a request
  that needs a memory allocation
* memory allocation triggers direct reclaim
* direct reclaim waits on a folio under writeback
* the FUSE server can't write back the folio since it's stuck in
  direct reclaim
(more details can be found here [1])

The first patch adds an ASOP_NO_RECLAIM_IN_WRITEBACK flag to the struct
address_space_operations to indicate that reclaim when in writeback should
be skipped for filesystems with this flag set. More details can be found in
the commit message of the first patch, but this only actually affects the
case of legacy cgroupv1 when it encounters a folio that already has the
reclaim flag set (in the other cases, we already skip reclaim when in
writeback). Doing so allows us to get rid of needing to allocate and copy over
pages to a temporary folio when handling writeback in fuse (2nd patch).
Benchmarks can be found in commit message of the 2nd patch.

Thanks,
Joanne

[1] https://lore.kernel.org/linux-kernel/495d2400-1d96-4924-99d3-8b2952e05fc3@linux.alibaba.com/

Joanne Koong (2):
  mm: skip reclaiming folios in writeback contexts that may trigger
    deadlock
  fuse: remove tmp folio for writebacks and internal rb tree

 fs/fuse/file.c     | 321 ++++-----------------------------------------
 include/linux/fs.h |  14 ++
 mm/vmscan.c        |   6 +-
 3 files changed, 45 insertions(+), 296 deletions(-)

-- 
2.43.5


             reply	other threads:[~2024-10-11 22:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11 22:34 Joanne Koong [this message]
2024-10-11 22:34 ` [PATCH 1/2] mm: skip reclaiming folios in writeback contexts that may trigger deadlock Joanne Koong
2024-10-13  4:54   ` Shakeel Butt
2024-10-14 17:18     ` Joanne Koong
2024-10-11 22:34 ` [PATCH 2/2] fuse: remove tmp folio for writebacks and internal rb tree Joanne Koong
2024-10-13  4:56   ` Shakeel Butt
2024-10-14 17:24     ` Joanne Koong

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=20241011223434.1307300-1-joannelkoong@gmail.com \
    --to=joannelkoong@gmail.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=hannes@cmpxchg.org \
    --cc=jefflexu@linux.alibaba.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=shakeel.butt@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).