Received-SPF: pass (google.com: domain of linux-kernel+bounces-45667-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <4ef64fd1-f605-4ddf-82e6-74b5e2c43892@intel.com>
Date: Wed, 31 Jan 2024 10:20:25 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/9] mm/memory: optimize unmap/zap with PTE-mapped THP
Content-Language: en-US
To: David Hildenbrand <david@redhat.com>, <linux-kernel@vger.kernel.org>
CC: <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, "Matthew
 Wilcox" <willy@infradead.org>, Ryan Roberts <ryan.roberts@arm.com>, "Catalin
 Marinas" <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, "Aneesh
 Kumar K.V" <aneesh.kumar@linux.ibm.com>, Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>, Michael Ellerman <mpe@ellerman.id.au>,
	Christophe Leroy <christophe.leroy@csgroup.eu>, "Naveen N. Rao"
	<naveen.n.rao@linux.ibm.com>, Heiko Carstens <hca@linux.ibm.com>, "Vasily
 Gorbik" <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle
	<svens@linux.ibm.com>, Arnd Bergmann <arnd@arndb.de>,
	<linux-arch@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>,
	<linux-s390@vger.kernel.org>, "Huang, Ying" <ying.huang@intel.com>
References: <20240129143221.263763-1-david@redhat.com>
From: Yin Fengwei <fengwei.yin@intel.com>
In-Reply-To: <20240129143221.263763-1-david@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WGM5bU15d2Z3cmFTWkZEdGhSM0hkVUVQTFdtSUpMN000Y0tpdUxlU1ViTi9a?=
 =?utf-8?B?cFlYRTVaVUJhTkR0V1J2b3lvdVZ0ckxPSGtOQzQzM0hpLzFjS25xbTNXZ2pi?=
 =?utf-8?B?bWZLR3pZV29rY2tWSnBBNHVsZEliZDZLb3RXSlJ6NGR4K0tJWi9walcxS1Ri?=
 =?utf-8?B?MlNOdWNTdnNmY1N1UEdub09zenMvd3EvUEhJNnhHbFBBOGsvTEQ5eWZNd0xw?=
 =?utf-8?B?a3UxbTQ4RENpNUc1SUtHa1htYUF6ZTdwOGlmY2pwaHhhTkwzSkN1am14bkoy?=
 =?utf-8?B?VWl0dVJQOEk3THorN3BZbUg5cDdyUlhmalRieE9lUEFhRE9pYTJOMWp0dlpm?=
 =?utf-8?B?NXV0SWMrMUlCMFR3akhaOTlxTHcrd3psZTBSV2Yrck5IcmVtaVdHdkRWYlZ0?=
 =?utf-8?B?a1ltK0p6UDRxQ21nYTJKQ20vNEh6VGxjenplUU5raGRmSmJOUytqT3JEeUxF?=
 =?utf-8?B?M1d3QVJCZWwxNW03RFFZT0U5L2REcnhtdGgvNFp5R3FQZFJ5dVkrTmNPT1Rs?=
 =?utf-8?B?dG5ockxyaDU0NE4xQ2NsUmM3dWNPYVJ4OUxNYlRtdkJNWnh0eE5PV2gwd3VT?=
 =?utf-8?B?Qkx0V0gwQzl0eEFQY295cm94Y296bXhDR2FScHlUT3RGa2dTQTNUbjlPNTk4?=
 =?utf-8?B?alIydmhRTXBNN0Jma3ZwcW04OXFkemQxejNZOTVCTUo5SGJGZnNSQVJJYUpk?=
 =?utf-8?B?YTZnMW91bllnL2U3SHo0ekZpcVMxYWNiNyt4UkRxcjZtZjNtZVBMTzVQOXRp?=
 =?utf-8?B?RTVnZlJUMXUrR0taTzJ3dEh0a3ZQY0piT05RRjlLNjA2dk1vK0JTTFNsSStY?=
 =?utf-8?B?TFcrR3VvSlQwK0VqanQ0NjdtME0rbis2ZHZoM3JhQm8wMGxLR2RNZXg4b3hK?=
 =?utf-8?B?MjVnWTBKMmJCRFNqYUo4TGdkdEsvTDJwSGdEL1J1UWwyV1FZbTA3b3NUSmg0?=
 =?utf-8?B?VHN3MmdKNmp6VnY2dFhxOVI4cnNCdDhRa25kaWxpVDNEMG8zSEJpZGJPVzln?=
 =?utf-8?B?aWUvdWZwZXRYeXhJWVJpZlNGOWxWQTcrNkhRM0JoaWd3ZTFvSFhXWGNCTUF0?=
 =?utf-8?B?eHBEbHF3V3dzRkk3MmJUVENMMStmdmx2VGZ6V1ZKMnVtY2N1cDkweEl6V2Y3?=
 =?utf-8?B?WndnZ3I5R21udnY3UlNxN3ptR1JSS2Q3WkFZZG1Tck83cG5CZ3Q1R0RLb1RN?=
 =?utf-8?B?S3ZoWitkY1VEdURxWWV2VmFrSWRyQzZOQUV6MStKSmQ1RDdWbnRLRkJkbk1B?=
 =?utf-8?B?RWlCS2RNSFBVMnFYcXhmY1hVa1N0cU9IcVZlbU9KQlBmTVJHaVZnc2xHRzE4?=
 =?utf-8?B?TVZoOXJ0dTNPbktTejA4OHBmVjNlMS9mYS9saEVxcnJydEJtaWtqU3paWkky?=
 =?utf-8?B?NmEyZ3ZmWm5yUWgwMHhtMXNyTFpsSzAvSnc1RnF3UUhvM3AxL3pjdU9jQmlX?=
 =?utf-8?B?YnFKWmVKaUhpdVdVQlFOaUEzYndvcUUwMDlCeS92eWxnUnVPdk5VbUNxRS9v?=
 =?utf-8?B?dkdzcVdkcFMza3lPdUNRUWwwaytOaVlyRlUyenNac2FZeVA4SlJpZkFjc0Zk?=
 =?utf-8?B?TFFweGJobzlyRWNGUFlNdW1oOGRmZ2Uzc01DMGd1Z2owRnlFK0ZKUlErcW5v?=
 =?utf-8?B?MmNodGdLTnpiYVpna0dIcWgvdmhEdDVnT2xrVlpsZWEwUWlNVng1TGcvc3Ru?=
 =?utf-8?B?Q1Z1cGVPbjdNU3pZN2hveEpldm4za2pzOXFjM0lJWG54blVCamUzVENwdFBX?=
 =?utf-8?B?WjZVMzZ1Rm1KS0pJZjZpVGZLWUMzY3RIZ0NmTjdLT0dMSGdhY2NrRGN1WnEw?=
 =?utf-8?B?QW16aWQyeVcxMWwzUWYzaVFKRWhBcDMrdndOcHAra1Q0MUI3UnNnM01SSnNS?=
 =?utf-8?B?OExCV290SXBCSUlkUVJxZ0ZNZmc4Q1FURG4wNFVUMnVPODJMMmN5dVJ0MHVR?=
 =?utf-8?B?WjhYdllXY3VwcG96REpsVCtYeFVPaXhZUWZvUVJUc01ubVJSV3cxOWhmTjRk?=
 =?utf-8?B?TkQvZ2tlNDRhVnRtUSszbWEvSWNWZnpMcmQxcFhGM1l3YVVZUDl3L2ZyRk5n?=
 =?utf-8?B?RXZYSUhCZDhsYkkvVzh6a29GdTZvVi9lTHIxbUNFUUhDaThXNGE5YWFwYW1U?=
 =?utf-8?Q?ejcrAVHk1iivokXMB6p/rldxi?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 34800384-6fb1-40df-3231-08dc22033545
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2024 02:20:35.6539
 (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: D5b1OpTZEVgJS22Q/ezWAvFl25ehjA6b+DS4JkjE80SoFucAI+bg9osltQoEmvF+Gm4iTJHzim+CCoBU6sVwvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4680
X-OriginatorOrg: intel.com

On 1/29/24 22:32, David Hildenbrand wrote:
> This series is based on [1] and must be applied on top of it.
> Similar to what we did with fork(), let's implement PTE batching
> during unmap/zap when processing PTE-mapped THPs.
> 
> We collect consecutive PTEs that map consecutive pages of the same large
> folio, making sure that the other PTE bits are compatible, and (a) adjust
> the refcount only once per batch, (b) call rmap handling functions only
> once per batch, (c) perform batch PTE setting/updates and (d) perform TLB
> entry removal once per batch.
> 
> Ryan was previously working on this in the context of cont-pte for
> arm64, int latest iteration [2] with a focus on arm6 with cont-pte only.
> This series implements the optimization for all architectures, independent
> of such PTE bits, teaches MMU gather/TLB code to be fully aware of such
> large-folio-pages batches as well, and amkes use of our new rmap batching
> function when removing the rmap.
> 
> To achieve that, we have to enlighten MMU gather / page freeing code
> (i.e., everything that consumes encoded_page) to process unmapping
> of consecutive pages that all belong to the same large folio. I'm being
> very careful to not degrade order-0 performance, and it looks like I
> managed to achieve that.

One possible scenario:
If all the folio is 2M size folio, then one full batch could hold 510M memory.
Is it too much regarding one full batch before just can hold (2M - 4096 * 2)
memory?


Regards
Yin, Fengwei