[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHk-=wgijo0ThKoYZeypuZb2YHCL_3vdyzjALnONdQoubRmN3A@mail.gmail.com>
Date: Sat, 18 Oct 2025 07:56:48 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kiryl Shutsemau <kirill@...temov.name>
Cc: Andrew Morton <akpm@...ux-foundation.org>, David Hildenbrand <david@...hat.com>,
Matthew Wilcox <willy@...radead.org>, Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Kiryl Shutsemau <kas@...nel.org>
Subject: Re: [PATCH] mm/filemap: Implement fast short reads
On Fri, 17 Oct 2025 at 04:15, Kiryl Shutsemau <kirill@...temov.name> wrote:
>
> To address this issue, introduce i_pages_delete_seqcnt, which increments
> each time a folio is deleted from the page cache and implement a modified
> page cache lookup protocol for short reads:
So this patch looks good to me, but to avoid the stack size warnings,
let's just make FAST_READ_BUF_SIZE be 768 bytes or something like
that, not the full 1k.
It really shouldn't make much of a difference, and we do have that
stack size limit check for a reason.
And obviously
> --- a/fs/inode.c
> +++ b/fs/inode.c
> + seqcount_spinlock_init(&mapping->i_pages_delete_seqcnt,
> + &mapping->i_pages->xa_lock);
will need to use '&mapping->i_pages.xa_lock', since mapping->i_pages
is the embedded xarray, not a pointer to it.
But I do think the patch looks quite good.
Linus
Powered by blists - more mailing lists