Received-SPF: pass (google.com: domain of linux-kernel+bounces-158028-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <18b9acc9-9dc8-4857-83d1-952c94b69e01@nvidia.com>
Date: Wed, 24 Apr 2024 22:40:21 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] mm/khugepaged: replace page_mapcount() check by
 folio_likely_mapped_shared()
To: Matthew Wilcox <willy@infradead.org>
Cc: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org,
 linux-mm@kvack.org, linux-doc@vger.kernel.org,
 Andrew Morton <akpm@linux-foundation.org>, Jonathan Corbet <corbet@lwn.net>,
 "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
 Zi Yan <ziy@nvidia.com>, Yang Shi <yang.shi@linux.alibaba.com>,
 Ryan Roberts <ryan.roberts@arm.com>
References: <20240424122630.495788-1-david@redhat.com>
 <73de5556-e574-4ed7-a7fb-c4648e46206b@nvidia.com>
 <ZinZSDTMXjPjAHLe@casper.infradead.org>
Content-Language: en-US
From: John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <ZinZSDTMXjPjAHLe@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
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?aU5SSUFDQXhPSzA1ZkZtcmVmN2hyM0U3TkF0VzZLWGFaSkJ6V2R6NEtndkJI?=
 =?utf-8?B?R0hpTzhvTVR1enJpZ0piaEVxUUhIdDBmSU8zMDNScWNxNm1maDVEWGEzMkdZ?=
 =?utf-8?B?a0FZei9YT2cwbmFEZ25RT2V3M1JoYmIxWm52TlRJRURnQ1VFU1ljVnU2aFlo?=
 =?utf-8?B?WktRaENzTmdIRnFFYW9iR1JKN3lmbzJwU0I0YWwwcmM2NDdNT0RYR0RWTGph?=
 =?utf-8?B?TEh0bHZFODc0TFhtYVEzSm52VWM2QkRnTytOT0RUT0d4ZCtycE5uZVVQNVJj?=
 =?utf-8?B?OEtVU040eExWeXo1SmZ2VnlkWXU3U1IyS3AwcHc3Wi9UMEswNC9ueVdVNzd1?=
 =?utf-8?B?dEdlSWhiUktzNndmZ1gvcGdhMExmK2lhZ1dJdWk4eVBXOG1BRGJjOHhHNSt1?=
 =?utf-8?B?c1NjaEVpZ3V5S21oN3JDTUJEdUNla0swanF1TGpUc2ZNTFpQTFVEZm04VXlq?=
 =?utf-8?B?dGIxNG9YRlZiR1VOQjg0eU5XVFg0c29kVnJ1SW5zRVovRTFObmc0Y1Bla3pZ?=
 =?utf-8?B?S3ZLUzc2YXdsK01ydXlFWGh3c3o2enNDS05PQ1ozdnhoc1VkSzRxZGlXSmxu?=
 =?utf-8?B?bmNOMnpsd2t4ckxUNG1aWHBDVDFEVHR0RmRYejFodU5rZTBhS29Vd2lDQ1kr?=
 =?utf-8?B?d0VVcXhQZHlGT2ZFZjAxWFk5TjdOa2J2YmZRTmJIVWxrYmYrV0ViRmMrT0JP?=
 =?utf-8?B?RFh6REhQSmJ6QUM1Nnl3Z1BpNjdPdnJVNFY1M1RRRG9vUm9JQlhlaG4zVFdL?=
 =?utf-8?B?Uitsai9PWVZqKzU1VC9BMXl3Q21kc3ZHc2RUOTV2cHp2ZFE1aDE5Z0Z0TUk0?=
 =?utf-8?B?N2xtVHA4MDRpOFh3ZEpKUCt4RnVZd0E4MzMvWDU2cEFOamJXNGVGYTFIckZN?=
 =?utf-8?B?blFOUHhnWEJjRnN4aXRFbTVJeDdjWjhQcUcrQmlZcGVZK3lFMFRweFNVUTBz?=
 =?utf-8?B?YkprQkVyaGVLSXdvUm9vbkpzam44WDFRalloQ09BcmdJdGErNTQyWjQ1UlZj?=
 =?utf-8?B?b0hvVzdTNVpEYzZWVlRROHd3akhCN1Q3eThwLzMxcDBSaVNGQmdyMWE2aVRQ?=
 =?utf-8?B?aW5nSmZZMWNDemwvZG9BM1N5cW9CbU9MVHRoVkFDeWFvQ3Y4UklzL1NpWnJv?=
 =?utf-8?B?M2VCeE41UUl6am9xTWloM2sycHF3UFNOa0pUYVJoNU5FL2lNWDRGVng3Nitv?=
 =?utf-8?B?QU9nYnZyWWl0bDViVE5mNys1bnA0VkFmcXNMQ3V4WGZFcGExbE9ISzlzRWp5?=
 =?utf-8?B?ZFY2NStrT3JmQnROTlpTZzR4QXZaUUZoTmZDczJwZHAreW16UDh1OHc3RVE1?=
 =?utf-8?B?Y3l1eTBWMzZqeC8rcXlwMUw1QkY4THpVanVKbm1ZVGkvQVdJdTB0aXhEUHc4?=
 =?utf-8?B?L0w0VUV5K25neEd4OW91VFZMMGxTSno4UnFCd3Jia0FCcXRXWVg4VGRiNURq?=
 =?utf-8?B?c242Z0RuaFVoY0RucTFLei9iWXhqcFYrZURvQllpL09ES1VFdFZGZ0c2SEJM?=
 =?utf-8?B?N0dNb3k3L3ZEWXVOMVg5WlcvaXgyVWNaN3NtWEdtKzExWGdJbmtFM2xMNDBI?=
 =?utf-8?B?MWJPd21WK24vWU5DTy92QUhHTWlGOU1rVFhZYXd3bjE3bXd5NG1NMkh0T3l2?=
 =?utf-8?B?TkxvcktsTnB4TTErN0l0ZjZ2SzZOK1Nzbk5yNytZZlFFVWdodjJXdzlsWms1?=
 =?utf-8?B?bnNwYnYwcjNHd21zbVd4bmkwb2FSTjFINVNFZ2xkWW9XOFR3OVNsaDc4bWxU?=
 =?utf-8?B?NjNiYS9wMHRtbitRT2ZNVzRoK1pHRHpFUG9sTDFkOWdUdlNFQVd2OXF1N3Mx?=
 =?utf-8?B?Q21FM1E4OWdPa0lkcjFEQnNvaytsbDZ6R2F1clZLS0VvMmEwdkllaS9RREtz?=
 =?utf-8?B?WUttUVhaRFJlaW56UVRsWFdZSE5KMlczMFhxY05xd05obUM0UWkwWTR0Ynpl?=
 =?utf-8?B?V2ZNcS9zYlEyQkNKMmEvUEpxcWdZZVFoTzZNMVRxYldOZ3ByS21HSGhWVTBM?=
 =?utf-8?B?Y0pucndwTmkzakxJeGtYNjg4MTBHWDFWaDRjMnYrOHV1emZzeGV0N2hNaHlC?=
 =?utf-8?B?UGlKMUF0TFBRNWM4eHVwOVVIZlhkVWcrdkxZa1JGaktReVU1ODllalh2MlBk?=
 =?utf-8?B?ZCtycytkODRJbW9rd1NxeGdUbkMyQXZUNjV6ZU1VSHpZR1RaTFFQOC9lV0Y3?=
 =?utf-8?B?UFE9PQ==?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c137be5-3c1f-4d67-e846-08dc64ea359d
X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4130.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2024 05:40:26.5496
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jdX/mGV4W6D+bVDEj9p92Yqzi2fEqy0vLz+xNxUyNOIpaIAdmzTj7FRmuYISQtFEb8/w/MVSSrWFKdR8CsM6Zg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4430

On 4/24/24 9:17 PM, Matthew Wilcox wrote:
> On Wed, Apr 24, 2024 at 09:00:50PM -0700, John Hubbard wrote:
>>> We want to limit the use of page_mapcount() to places where absolutely
>>> required, to prepare for kernel configs where we won't keep track of
>>> per-page mapcounts in large folios.
>>
>>
>> Just curious, can you elaborate on the motivation? I probably missed
>> the discussions that explained why page_mapcount() in large folios
>> is not desirable. Are we getting rid of a field in struct page/folio?
>> Some other reason?
> 
> Two reasons.  One is that, regardless of anything else, folio_mapcount()
> is expensive on large folios as it has to walk every page in the folio
> summing the mapcounts.  The more important reason is that when we move
> to separately allocated folios, we don't want to allocate an array of
> mapcounts in order to maintain a per-page mapcount.
> 
> So we're looking for a more compact scheme to avoid maintaining a
> per-page mapcount.
>

I see. Thanks for explaining the story.

>>> The khugepage MM selftests keep working as expected, including:
>>>
>>> 	Run test: collapse_max_ptes_shared (khugepaged:anon)
>>> 	Allocate huge page... OK
>>> 	Share huge page over fork()... OK
>>> 	Trigger CoW on page 255 of 512... OK
>>> 	Maybe collapse with max_ptes_shared exceeded.... OK
>>> 	Trigger CoW on page 256 of 512... OK
>>> 	Collapse with max_ptes_shared PTEs shared.... OK
>>> 	Check if parent still has huge page... OK
>>
>> Well, a word of caution! These tests do not (yet) cover either of
>> the interesting new cases that folio_likely_mapped_shared() presents:
>> KSM or hugetlbfs interactions. In other words, false positives.
> 
> Hmm ... KSM never uses large folios and hugetlbfs is disjoint from
> khugepaged?
> 

Oh good. I thought we might have had a testing hole, but no.


thanks,
-- 
John Hubbard
NVIDIA