On Tue, May 26, 2026 at 01:21:33AM +0000, Jaegeuk Kim wrote: > On 05/24, Christoph Hellwig wrote: > > On Fri, May 22, 2026 at 02:04:59PM +0000, Jaegeuk Kim wrote: > > > This was a quick buddyinfo right after booting the device. > > > > > > Before: > > > Node 0, zone Normal 22684 42284 28704 16901 9515 4566 1854 > > > 673 181 36 758 > > > > > > After disabling EROFS large folio: > > > Node 0, zone Normal 8486 4732 2175 1161 697 272 82 > > > 19 3 1 856 > > > > And what are you trying to say us with that? > > This means, high-order pages were used up by EROFS which sets large folio by > default. So, I wanted to say the concern was based on actual data which was > what > Mattew asked.
This isn't that though. What you actually need is to show that high order allocations are _failing_. The MM is far more complicated than you seem to understand. There isn't a fixed number of large folios available; when we try to allocate memory, we do reclaim. And if there's large folios on the LRU list, you'll get them. If what you want is large folios readily available, then what you want is large folios used _everywhere_ because then they're easy to get! If there's small folios in use, you need to reclaim a lot of memory in order to reassemble large folios (it's the birthday paradox, similar to the hash collision problem). _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
