Re: [PATCH 3/3] xfile: implement write caching

Darrick J. Wong
2024-01-04T07:20:51Z

On Wed, Jan 03, 2024 at 10:20:34PM -0800, Christoph Hellwig wrote:
> On Wed, Jan 03, 2024 at 05:33:56PM -0800, Darrick J. Wong wrote:
> > Sort of both. For xfbtrees (or anything mapping a xfs_buftarg atop an
> > xfile) we can't use the cheap(er) kmap_local_page and have to use kmap,
> > which ... is expensive, isn't it?
>
> A little, but not really enough to explain the numbers you quoted..
>
> > Granted, forbidding highmem like you posted today makes all of this
> > /much/ simpler so I think it's probably worth the increased chances of
> > ENOMEM on i386.
> >
> > That said, why not avoid a trip through shmem_get_folio_gfp aka
> > filemap_get_entry if we can? Even if we can use page_address directly
> > now?
>
> Sure, I just suspect the commit message is wrong and it's not about
> mapping the page into the kernel address space but something else.

Yeah, I only did A/B testing of before and after this patch, so it's
quite plausible that it's the lookup that's slowing us down.

"xfile: implement write caching

"Cache a few of the most recently used pages in the hopes of saving
ourselves a few trips through shmem_get_folio_gfp. There's enough time
savings to shave a few percent off the runtime of fstests with online
fsck enabled."

How about that? I guess I could modify this patch in djwong-wtf not to
cache kmappings and retest, but that seems like a lot for a patch that
is pretty simple after it goes on a diet. :)

--D