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
