On 3/10/26 15:02, Gao Xiang wrote: > > > On 2026/3/10 14:43, Chao Yu wrote: >> Xiang, >> >> On 3/9/26 11:03, Gao Xiang wrote: >>> Hi Chao, >>> >>> (+cc -fsdevel, willy, Jan kara) >>> >>> On 2026/3/9 10:30, Chao Yu wrote: >>>> This patch introduces a new mount option 'nolargefolio' for EROFS. >>>> When this option is specified, large folio will be disabled by >>>> default for all inodes, this option can be used for environments >>>> where large folio resources are limited, it's necessary to only >>>> let specified user to allocate large folios on demand. >>> >>> For this kind of options, I think more real backgrounds >>> about avoiding high-order allocations are needed in the >>> commit message (at least for later reference) also like >>> what I observed in: >>> https://android-review.googlesource.com/c/kernel/common/+/3877981 >> >> Basically, the background is about contention scenario on large folio >> allocation, >> it's among multiple users including EROFS in Android-system, as it's related >> to >> internal scene of product, so I can not provide more details now, I'm sorry >> about that, but I'm glad to discuss based on the background and pain point >> once >> if I can share more, let's see. :) > > Understood, but I think it's hard to justify an upstream > solution without a public load for discussion. Anyway, > I can imagine some real workloads which large folios could > cause unnecessary pressure since I once worked for Android, > but I think others need an explicit one anyway to justify > this.
Yes, > > As Matthew and Jan mentioned, it's hard to add a per-fs > knob like this. If it's Android-specific and no possible > public infos, I suggest leaving the changes Android > downstream for now, until the workloads can be made public. Sure, I can understand that we're not going to accept per-fs change on large folio policy, as if there is conclusion or agreement about this in previous discussion from community. Thanks for the suggestion, I can take a look from downstream side. Thanks, > > Thanks, > Gao Xiang
