From: Christoph Hellwig <hch@infradead.org>
To: alexjlzheng@gmail.com
Cc: brauner@kernel.org, djwong@kernel.org, willy@infradead.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Jinliang Zheng <alexjlzheng@tencent.com>
Subject: Re: [PATCH v2] iomap: move prefaulting out of hot write path
Date: Thu, 31 Jul 2025 07:21:57 -0700 [thread overview]
Message-ID: <aIt8BYa6Ti6SRh8C@infradead.org> (raw)
In-Reply-To: <20250730164408.4187624-2-alexjlzheng@tencent.com>
On Thu, Jul 31, 2025 at 12:44:09AM +0800, alexjlzheng@gmail.com wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.com>
>
> Prefaulting the write source buffer incurs an extra userspace access
> in the common fast path. Make iomap_write_iter() consistent with
> generic_perform_write(): only touch userspace an extra time when
> copy_folio_from_iter_atomic() has failed to make progress.
This is probably a good thing to have, but I'm curous if you did see
it making a different for workloads?
> + /*
> + * Faults here on mmap()s can recurse into arbitrary
> + * filesystem code. Lots of locks are held that can
> + * deadlock. Use an atomic copy to avoid deadlocking
> + * in page fault handling.
We can and should use all 80 characters in a line for comments.
> + /*
> + * 'folio' is now unlocked and faults on it can be
> + * handled. Ensure forward progress by trying to
> + * fault it in now.
> + */
Same here.
I really wish we could find a way to share the core write loop between
at least iomap and generic_perform_write and maybe also the other copy
and pasters. But that's for another time..
next prev parent reply other threads:[~2025-07-31 14:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 16:44 [PATCH v2] iomap: move prefaulting out of hot write path alexjlzheng
2025-07-31 14:21 ` Christoph Hellwig [this message]
2025-07-31 14:56 ` Jinliang Zheng
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=aIt8BYa6Ti6SRh8C@infradead.org \
--to=hch@infradead.org \
--cc=alexjlzheng@gmail.com \
--cc=alexjlzheng@tencent.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.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.