On 05/07/2023 00:57, Matthew Wilcox wrote: > On Tue, Jul 04, 2023 at 03:20:35PM +0100, Ryan Roberts wrote: >> On 04/07/2023 04:45, Yin, Fengwei wrote: >>> >>> On 7/3/2023 9:53 PM, Ryan Roberts wrote: >>>> Introduce FLEXIBLE_THP feature, which allows anonymous memory to be >>> THP is for huge page which is 2M size. We are not huge page here. But >>> I don't have good name either. >> >> Is that really true? On arm64 with 16K pages, huge pages are 32M and with 64K >> base page, they are 512M. So huge pages already have a variable size. And they >> sometimes get PTE-mapped. So can't we just think of this as an extension of the >> THP feature? > > The confusing thing is that we have counters for the number of THP > allocated (and number of THP mapped), and for those we always use > PMD-size folios. OK fair point. I really don't have a strong opinion on the name - I changed it from LARGE_ANON_FOLIO because Yu was suggesting it should be tied to THP. So I'm happy to change it back to LARGE_ANON_FOLIO (or something else) if that's the concensus. But I expect I'll end up in a game of ping-pong. So I'm going to keep this name for now and focus on converging the actual implementation to something that is agreeable. Once we are there, we can argue about the name. > > If we must have a config option, then this is ANON_LARGE_FOLIOS. > > But why do we need a config option? We don't have one for the > page cache, and we're better off for it. Yes, it depends on > CONFIG_TRANSPARENT_HUGEPAGE today, but that's more of an accidental > heritage, and it'd be great to do away with that dependency eventually. > > Hardware support isn't needed. Large folios benefit us from a software > point of view. if we need a chicken bit, we can edit the source code > to not create anon folios larger than order 0. >From my PoV it's about managing risk; there are currently parts of the mm that will interact poorly with large pte-mapped folios (madvise, compaction, ...). We want to incrementally fix that stuff, but until it's all fixed, we can't deploy this as always-on. Further down the line when things are more complete and there is more test coverage, we could remove the Kconfig or default it to enabled.
