On Fri, Dec 06, 2024 at 09:41:25AM -0800, Joanne Koong wrote:
> On Fri, Dec 6, 2024 at 1:50 AM Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote:
[...]
> >
> > >
> > > Writes are still effectively one page size. Benchmarks showed that trying to get
> > > the largest folios possible from __filemap_get_folio() is an over-optimization
> > > and ends up being significantly more expensive. Fine-tuning for the optimal
> > > order size for the __filemap_get_folio() calls can be done in a future patchset.
>
> This is the behavior I noticed as well when running some benchmarks on
> v1 [1]. I think it's because when we call into __filemap_get_folio(),
> we hit the FGP_CREAT path and if the order we set is too high, the
> internal call to filemap_alloc_folio() will repeatedly fail until it
> finds an order it's able to allocate (eg the do { ... } while (order--
> > min_order) loop).
>
What is the mapping_min_folio_order(mapping) for fuse? One thing we can
do is decide for which range of orders we want a cheap failure i.e. without
__GFP_DIRECT_RECLAIM and then the range where we are fine with some
effort and work. I see __GFP_NORETRY is being used for orders larger
than min_order, please note that this flag still allows one iteration of
reclaim and compaction, so not necessarily cheap.
