On Tue, Feb 07, 2023 at 10:44:10AM +0800, Yin, Fengwei wrote: > On 2/7/2023 12:50 AM, Matthew Wilcox wrote: > > On Mon, Feb 06, 2023 at 11:30:49PM +0800, Yin Fengwei wrote: > >> Remove parameter 'compound' from folio_add_file_rmap_range(). > >> > >> The parameter nr_pages is checked whether same as folio page > >> numbers to know whether it's entire folio operation. > > > > We can't do this yet. Even if a folio is large enough to be PMD mapped, > > it may have been mapped askew (or its PMD mapping may have been split). > > We still need the caller to tell us whether it's been mapped with > > a PMD or with PTEs. > OK. My understand is that the info about PMD mapped is only for > statistic update. Maybe move the PMD mapped statistic to caller. Alas, no. That 'compound' parameter really means "to be mapped by a PMD". And we need to change all of add_file, add_anon and remove at the same time, otherwise we don't know which counter to inc/dec in page_remove_rmap(). > Another thing I am not sure whether it's worthy: > What about maintaining total mapcount for folio? So we don't need to > query each page mapcount to know it. So we can use "total_mapoucnt > > mapped" to know whether the folio has at least one page mapped more > than once. > > The payback is that we need update total mapcount when map/unmap > the folio. Right, there are lots of mapcounts we _could_ maintain. The important thing to understand is who wants to know what. As I see it, there are three important things we need to know: 1. Is any page in this folio mapped? (everywhere that calls folio_mapped() or page_mapped()) 2. Is any page in this folio mapped more than once? (some madvise calls, migration) 3. How many refcounts does the mapcount account for? (splitting, compaction) Some of the things we use mapcount for today I consider to be unimportant. For example, shrink_folio_list() checks to see if there are any PMD mappings and will split it if there are not. This doesn't fit my vision of how the VM should work; I believe we should swap the entire folio out as a single unit. So I don't really want to think about maintaining total_mapcount, I want the concept of total_mapcount to go away and just have a single mapcount for each folio, instead of this complex mismash of entire_mapcount, mapcount and total_mapcount.
