Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b3c20fd8-3835-517a-a055-cd796fa7f733@intel.com>
Date:   Tue, 18 Jul 2023 07:27:39 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.11.0
Subject: Re: [PATCH v1 3/3] mm: Batch-zap large anonymous folio PTE mappings
Content-Language: en-US
To:     Ryan Roberts <ryan.roberts@arm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        "David Hildenbrand" <david@redhat.com>,
        Yu Zhao <yuzhao@google.com>, Yang Shi <shy828301@gmail.com>,
        "Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>
CC:     <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
References: <20230717143110.260162-1-ryan.roberts@arm.com>
 <20230717143110.260162-4-ryan.roberts@arm.com>
From:   Yin Fengwei <fengwei.yin@intel.com>
In-Reply-To: <20230717143110.260162-4-ryan.roberts@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?REU4dW53MU5jVGd6VzJWdHl4UUM5QUhvV0JCcjRFelB1QXZ5aHlhVDFiVFlY?=
 =?utf-8?B?UzdabXVpT1NlT2JwcmlLSzJ4ZUhGQzRaNlpoMHF0NTFCN1E4L3NtYWRUQzdo?=
 =?utf-8?B?TEdGQ0FMOTdGRDdUalUwMTF4TTJvT1hCSlBHWDdSQTdpeDVLY0UrRno5djZR?=
 =?utf-8?B?cWplM2ZUT1Z1VDY0bmJrbm9odjE1SnlCaVk5MUhjV1FUVURGQVZDRmxrSStn?=
 =?utf-8?B?Y0x2MFBuN1BOa1E1a1FkdGZPdUoxeHlwMFlkNXlicTNYTmZseEhib3cwSnR4?=
 =?utf-8?B?cWw3SGxSak1BS0V1TVBTVC9MUllEOWdCeWZqcmdYcG15Y21oYVJScmpkZjl4?=
 =?utf-8?B?QVhSS0thVCs1ZjdQd3poa0d1d0QwWmFtTHNGKzJzQ2Y5YXZCNnRpYzBMTjRu?=
 =?utf-8?B?NWQ4VjZhY3hmL1FmSURjaW1GKzRzbFdwTzh4NEJPN1E2SDQwSytUWWZHaEZF?=
 =?utf-8?B?MHdwTkluVktqcGpoYXF1TzhQQmhteWtxMTN4N1YzVzJZSHdrU1Z2cjFHTU5U?=
 =?utf-8?B?WDU4SDh6T0hKU1c3eGRtaXYxeklJUks4UzR4bmJPc3JSQXpaWVppaHp2dWs1?=
 =?utf-8?B?SHl6YUlYbGFzSUpZdmlXbEVUV2xES0dBWHlQNy9DRUZ2SDMvK0c2OUgxVTU3?=
 =?utf-8?B?Mmt1b1NhVHJ3M1p6dzBaMkZCdDlwR1VrL3pvSlRDZkJnOU5JUkRYV1BzUHRC?=
 =?utf-8?B?ZTlDTDZidzErOVpDdkgyYkFibGJ4NkM0Z3g1aGl6YWpuOE5GZDBaSm9iSEJH?=
 =?utf-8?B?U3d5TThnb3BMUmxZNjY4SG94UFhTcGdubFlOOW5XRjNSRkNzTHhGMlR6bEl3?=
 =?utf-8?B?cUR1R2xKU0pYL28zTDVPZkdENHhTL2lvRTlyZ21hYzNoWXRuUzVxSzRSbmky?=
 =?utf-8?B?OXUwM2QzNTR6dnFxaEFGdVRSTEphTEFrSnFZcVRRZnk4UEdLc2N0c0dVenYr?=
 =?utf-8?B?S1ZEb2YzaHlid0R6VEQ4cW03WFc2U0NGdUlsU2lHaG1WN1ZvNW16dnJTeFhZ?=
 =?utf-8?B?NGs0Q0hjQTNxL1MxdWJNSGdXV0poNDlPc004YjhHZjdLc0hPenEvYnpLaTd4?=
 =?utf-8?B?d01pZUhtaHVtTVRaaU12YjN6Zjk0aGtiSzdBbXRBTkpnZ1hNS0FKL2tGN0NM?=
 =?utf-8?B?dythU050cy9rK1dPem5jRkY0MU9IVWVFdy82L1IvaWFJR2RFcFZkTGFsOGVr?=
 =?utf-8?B?L09xVklrVHUrU3V1dmo5OHFlNGExMmZPTXRieVp4SWV1MW9LWGNTN1ZKTjhL?=
 =?utf-8?B?ZEZYcTJ5ZDI0Q1BJNFFLVFhPdmNYZ1Uxb01BUkdhU3hPMGhrekF6dWwvNnBs?=
 =?utf-8?B?K3dxdWsvaDZYTnNlcEJRR3ZZc1MrVHdnOGdtcXp5R1JqYjdoMEw5dGk0ejU4?=
 =?utf-8?B?bi9JQ0lUOUVTSTVJS2lzMEJxNmFDZUhRU1o3TVN3SlVuRTBKN1pMNTZ0dDRl?=
 =?utf-8?B?UVc1YnF4WUZjV3FPWGtEMVlPc1kzSCt1cDcxZnNWV05ESWpzVHdBM01kUk03?=
 =?utf-8?B?RS9rd3dtcFlDOXh5cjZ4QUJwTmRBMGpOdDVjUUl0VTlkT1JpYXVyQitPcklq?=
 =?utf-8?B?WnpNc3lpbXFOSjd3TnFXaDMzZ1pLT1hxUmFCbHFZRERQSXZjMDVCeDA2R0k4?=
 =?utf-8?B?cm5FR29rb1N3UlNFdHA0emFYMUkwR0s1cVlzT3J0YXlzM2V1ZEFmUkpUamxv?=
 =?utf-8?B?YnVDRjdtUlhKSXYzTGdyWGh3YXV3cVRaU0V6bVBoeGtnOC9Tc3NvRzJYV2VQ?=
 =?utf-8?B?Wm9UZ2tMcTBGRUZaZmhNOXlwa244RSt3d0d6UzYzQ0UwY1pzUVJYZ0c0RnVH?=
 =?utf-8?B?czB6SzQwVDZPb2JyZytpanM3NEN6Wk1CTHhwWHFGM3FjcUJZeW9mVmc4Y1hP?=
 =?utf-8?B?VlpmWDMzZFRQUm5ENE5ybUQ1MGJWa3ZzOVV4U0NXVXJZaEEyOUtUZ0FvTmlT?=
 =?utf-8?B?c1pRbm1mWUkydXNsQndXVG1ZNEozSGpsVXNLb2NIQzBJZzA4aUZZV0pUVzI1?=
 =?utf-8?B?WVJpSVhiSUJlUzEzRDVTeVV6cm1XRG00bWN6cVRUdmhodE9NUmM5cXVldG0y?=
 =?utf-8?B?SVV5Q2RxWlhDcDBaTlBaZ3B3RDFyb2dwR2RKbTVTb3lvWUFGOXBuMzhtZm9X?=
 =?utf-8?Q?Fo+0AcL/evakqksb2KA3f/qvd?=
X-MS-Exchange-CrossTenant-Network-Message-Id: fc6bab64-7394-42ea-66e8-08db871d685f
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2023 23:27:37.9166
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0uIIFUUKjwp3T9rawJ8MI1MkNJgbKell1LLjg+3GMOaVgxeEVDWuybVzRSB8vaKmKKe7xNvIda5LYmpgi6dhiQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB5803
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 7/17/23 22:31, Ryan Roberts wrote:
> This allows batching the rmap removal with folio_remove_rmap_range(),
> which means we avoid spuriously adding a partially unmapped folio to the
> deferrred split queue in the common case, which reduces split queue lock
> contention.
> 
> Previously each page was removed from the rmap individually with
> page_remove_rmap(). If the first page belonged to a large folio, this
> would cause page_remove_rmap() to conclude that the folio was now
> partially mapped and add the folio to the deferred split queue. But
> subsequent calls would cause the folio to become fully unmapped, meaning
> there is no value to adding it to the split queue.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
>  mm/memory.c | 119 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 119 insertions(+)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 01f39e8144ef..6facb8c8807a 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1391,6 +1391,95 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
>  	pte_install_uffd_wp_if_needed(vma, addr, pte, pteval);
>  }
>  
> +static inline unsigned long page_addr(struct page *page,
> +				struct page *anchor, unsigned long anchor_addr)
> +{
> +	unsigned long offset;
> +	unsigned long addr;
> +
> +	offset = (page_to_pfn(page) - page_to_pfn(anchor)) << PAGE_SHIFT;
> +	addr = anchor_addr + offset;
> +
> +	if (anchor > page) {
> +		if (addr > anchor_addr)
> +			return 0;
> +	} else {
> +		if (addr < anchor_addr)
> +			return ULONG_MAX;
> +	}
> +
> +	return addr;
> +}
> +
> +static int calc_anon_folio_map_pgcount(struct folio *folio,
> +				       struct page *page, pte_t *pte,
> +				       unsigned long addr, unsigned long end)
> +{
> +	pte_t ptent;
> +	int floops;
> +	int i;
> +	unsigned long pfn;
> +
> +	end = min(page_addr(&folio->page + folio_nr_pages(folio), page, addr),
> +		  end);
> +	floops = (end - addr) >> PAGE_SHIFT;
> +	pfn = page_to_pfn(page);
> +	pfn++;
> +	pte++;
> +
> +	for (i = 1; i < floops; i++) {
> +		ptent = ptep_get(pte);
> +
> +		if (!pte_present(ptent) ||
> +		    pte_pfn(ptent) != pfn) {
> +			return i;
> +		}
> +
> +		pfn++;
> +		pte++;
> +	}
> +
> +	return floops;
> +}
> +
> +static unsigned long zap_anon_pte_range(struct mmu_gather *tlb,
> +					struct vm_area_struct *vma,
> +					struct page *page, pte_t *pte,
> +					unsigned long addr, unsigned long end,
> +					bool *full_out)
> +{
> +	struct folio *folio = page_folio(page);
> +	struct mm_struct *mm = tlb->mm;
> +	pte_t ptent;
> +	int pgcount;
> +	int i;
> +	bool full;
> +
> +	pgcount = calc_anon_folio_map_pgcount(folio, page, pte, addr, end);
> +
> +	for (i = 0; i < pgcount;) {
> +		ptent = ptep_get_and_clear_full(mm, addr, pte, tlb->fullmm);
> +		tlb_remove_tlb_entry(tlb, pte, addr);
> +		full = __tlb_remove_page(tlb, page, 0);
> +
> +		if (unlikely(page_mapcount(page) < 1))
> +			print_bad_pte(vma, addr, ptent, page);
> +
> +		i++;
> +		page++;
> +		pte++;
> +		addr += PAGE_SIZE;
> +
> +		if (unlikely(full))
> +			break;
> +	}
> +
> +	folio_remove_rmap_range(folio, page - i, i, vma);
> +
> +	*full_out = full;
> +	return i;
> +}
> +
>  static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  				struct vm_area_struct *vma, pmd_t *pmd,
>  				unsigned long addr, unsigned long end,
> @@ -1428,6 +1517,36 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
>  			page = vm_normal_page(vma, addr, ptent);
>  			if (unlikely(!should_zap_page(details, page)))
>  				continue;
> +
> +			/*
> +			 * Batch zap large anonymous folio mappings. This allows
> +			 * batching the rmap removal, which means we avoid
> +			 * spuriously adding a partially unmapped folio to the
> +			 * deferrred split queue in the common case, which
> +			 * reduces split queue lock contention. Require the VMA
> +			 * to be anonymous to ensure that none of the PTEs in
> +			 * the range require zap_install_uffd_wp_if_needed().
> +			 */
> +			if (page && PageAnon(page) && vma_is_anonymous(vma)) {
Why this is only for anonymous page? I suppose it can support file mapping also.


Regards
Yin, Fengwei

> +				bool full;
> +				int pgcount;
> +
> +				pgcount = zap_anon_pte_range(tlb, vma,
> +						page, pte, addr, end, &full);
> +
> +				rss[mm_counter(page)] -= pgcount;
> +				pgcount--;
> +				pte += pgcount;
> +				addr += pgcount << PAGE_SHIFT;
> +
> +				if (unlikely(full)) {
> +					force_flush = 1;
> +					addr += PAGE_SIZE;
> +					break;
> +				}
> +				continue;
> +			}
> +
>  			ptent = ptep_get_and_clear_full(mm, addr, pte,
>  							tlb->fullmm);
>  			tlb_remove_tlb_entry(tlb, pte, addr);