Re: [RFC PATCH v2 02/18] splice: don't steal page cache folios
From: Kiryl Shutsemau
Date: Thu Nov 05 2026 - 10:06:34 EST
On Wed, Nov 04, 2026 at 05:05:29PM +0100, David Hildenbrand (Arm) wrote:
> On 11/4/26 14:00, Kiryl Shutsemau (Meta) wrote:
> > From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> >
> > PG_rcu_free holds back the reuse of a folio's memory until a grace
> > period after the folio is freed. A stolen page cache pipe buffer is
> > reused without being freed: remove_mapping() takes the folio out of the
> > page cache and the caller keeps it. fuse_try_move_folio() puts it into
> > a fuse file, where writes change it under a reader that found it before
> > the steal.
> >
> > Drop ->try_steal from page_cache_pipe_buf_ops. fuse_try_move_folio()
> > and virtio_console's pipe_to_sg() then copy, as they already do when
> > stealing fails. SPLICE_F_MOVE from the page cache into a fuse file or
> > a virtio console now copies.
> >
> > Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > [kas: rewrote the changelog]
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> > ---
> > fs/splice.c | 51 ---------------------------------------------------
>
> Removing code is always nice, even independent of the other changes :)
>
> The description doesn't really describe the impact of this change. I assume a
> slowdown of certain workloads (does anybody really care?), and temporary
> increased memory consumption (as we keep the pagecache page).
>
> No idea how often stealing actually succeeds ... a bit of history why it was
> added in the first place and why we no longer care now would be nice.
SPLICE_F_MOVE has not moved page cache folios between files since 2007.
See 485ddb4b9741 ("1/2 splice: dont steal"). The only users that still
steal from a pipe are fuse, when a server splices into /dev/fuse with
SPLICE_F_MOVE, and virtio_console's splice_write(). With this patch
both copy, and the source file keeps its folio cached.
Miklos, Bernd, Amit: do you know of users that depend on the move? Would
the copy hurt them?
--
Kiryl Shutsemau / Kirill A. Shutemov