On Mon, Jul 10, 2023 at 04:58:55PM -0700, Luis Chamberlain wrote: > > @@ -1914,26 +1916,44 @@ struct folio *__filemap_get_folio(struct address_space *mapping, pgoff_t index, > > gfp &= ~GFP_KERNEL; > > gfp |= GFP_NOWAIT | __GFP_NOWARN; > > } > > - > > - folio = filemap_alloc_folio(gfp, 0); > > - if (!folio) > > - return ERR_PTR(-ENOMEM); > > - > > if (WARN_ON_ONCE(!(fgp_flags & (FGP_LOCK | FGP_FOR_MMAP)))) > > fgp_flags |= FGP_LOCK; > > > > - /* Init accessed so avoid atomic mark_page_accessed later */ > > - if (fgp_flags & FGP_ACCESSED) > > - __folio_set_referenced(folio); > > + if (!mapping_large_folio_support(mapping)) > > + order = 0; > > + if (order > MAX_PAGECACHE_ORDER) > > + order = MAX_PAGECACHE_ORDER; > > Curious how this ended up being the heuristic used to shoot for the > MAX_PAGECACHE_ORDER sky first, and then go down 1/2 each time. I don't > see it explained on the commit log but I'm sure there's has to be > some reasonable rationale. From the cover letter, I could guess that > it means the gains of always using the largest folio possible means > an implied latency savings through other means, so the small latencies > spent looking seem to no where compare to the saving in using. But > I rather understand a bit more for the rationale. You've completely misunderstood this patch. The caller hints at the folio size it wants, and this code you're highlighting limits it to be less than MAX_PAGECACHE_ORDER.
