From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 058C3C54E66 for ; Tue, 12 Mar 2024 08:12:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E2038D001D; Tue, 12 Mar 2024 04:12:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86B4C8D0017; Tue, 12 Mar 2024 04:12:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 733528D001D; Tue, 12 Mar 2024 04:12:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 612248D0017 for ; Tue, 12 Mar 2024 04:12:19 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 020D14043E for ; Tue, 12 Mar 2024 08:12:18 +0000 (UTC) X-FDA: 81887669598.24.D096399 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 2CF2640012 for ; Tue, 12 Mar 2024 08:12:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710231137; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I6EJm6YyU5P7tgJ9X0PsUs1Ij4WlZzyflfuBRGeds1g=; b=kqwpJO/zPJdwSDlWO6zUPNoGzJDBseKl3WI+GU4U1G30zNguce1RiiaVxgZ0cUU30HIef1 z/O4rcvsM9UFW+3VonTckpT4AuTVlh9NfMFwnYAD976OydJBVrqd8kITT1HA1sT5fPvK9d 530rV1aWq3Nt4CyMXR/WXZpMgY0sLeg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710231137; a=rsa-sha256; cv=none; b=ROQI9bmqREJMdw1HyRelmQWfThbH+/GaGcGyOUrUpiqQncIZoJ9TNYUoTfBb9E02n2ct1V X+Z8WdLOBKoiFjcTbjWsRf4CefLfPQ7PWRtOYmhzDW6QLoje1HRuwQCG8Aso46Q2DE7Mf/ Qrf0IGOxJ8GrPx7umExfyGrlsi0NbOs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36BCA1007; Tue, 12 Mar 2024 01:12:53 -0700 (PDT) Received: from [10.57.68.246] (unknown [10.57.68.246]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 48CD73F73F; Tue, 12 Mar 2024 01:12:13 -0700 (PDT) Message-ID: Date: Tue, 12 Mar 2024 08:12:11 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/6] mm: vmscan: Avoid split during shrink_folio_list() Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , Chris Li , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240311150058.1122862-1-ryan.roberts@arm.com> <20240311150058.1122862-6-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: bhgrm985g3mb4otqgi4mdrpgrr3qcgtm X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2CF2640012 X-Rspam-User: X-HE-Tag: 1710231136-565592 X-HE-Meta: U2FsdGVkX19BDCAYstNEHAtTzWkaKuSrdZGQNFOsCfqkRkCvU2Aq0t108zOWiGNM0Q5wzFk/ye983NZP3vv7IuymSBp4NlGX0THxN3YSSeDhWV00fKCs4/dm44v8+BqG3nAApelKYjpyKJIMUf/noNO8M5/k2S9B6KyZBfUHsuhMDSKTGiFDDYcbrNHIFgOfh8UQnKPbaHO0no79tiJ4lj/JdG+dyHhrmIon92psl0pyMcZubz72ZeZ9yltgyRTWjk8fiI9bJ++rV/3oK67XwWoCHAI1ttDrCQlWSAmPsMdNnKW8NXe4Ye0J4RKsQUNfPPjpIFiNl+v0lJYML5OJPHczZUuJQwraMWUBsyU9glxgqoRNYlIJ+A3kqYjd5hwQTw1Tdd82YvYLLe/yGNBHwogGhxaygaa5znkvUto8gSqZz+oN7Qx8kM8nyio6otpwxIm5QZIU+SXUh4XWIqdE8GdDvVgDHsuHuyAf72QCVX74yO8owVQZl9QVaBWsSruL2Ne7v9XSN8vuuGjIV6ZqbtmOqCZmPvNTrjhuJpjqDSmRkCTsdkSCxSg+SCWO0xMWd5BKFSYqYFymbaBrTWCbfnor0UoG+TuwgA7EN6f0LLbvMyrI/FYxmn+kG7MJih2KvGO7ABGMEqn3O5/+/OBoOlo4Ugwer2iiAELN5C9YkGDBUT++/697YG6P1CS1sVnvTuWlemEpOVHrk1d3evkVyng7OFlTeotiV9CuX39mJcPbUjA0gC3C3YhsX/jAnjLZqH9BvaGGvSs67ElSL9XYBzy76gamSrWy+Cc4VxxTh3fMkEKz5YNgNAA6UeUcD1teBUVdfKWh77jsFnJK+/7ZLEOjiP8+M5BFfXx3wqjrNI+02sXgniO3VGVA9NdJitUuFeG6r2FNCgcT+SWBE7xZPmwvrHegEqdszS2/XJ9YND2D8lkJWiy5c7LedT1DQNurxv0hvruIt6QwS3VmDgo rWvw39oq 1G778dEOEHUL2xKJ1uKwaNYaR/1U0EMVIngcskHuzSHCAEhGQOzD9HE5ydeTJ7Xj93/zlxhgs3LZ9FX/mW6PnLFcESY7YEDIIXRJL46Cs9NeaENf3lXTeYwOXXzEt8BKJ5ybQJGPJFULBz2Zd6DiMHuGsq5GVFLuMQR5qQpsAJ4oTCNseujospOfZZyMcemS1NjHXterWVXQ1Ek47T6rAgdaOX5mwnxogsEjwNfq1F9ZEq1GEvc43XQtWZTkGV5ZISixY59v3Abtu+RtMIFG60rnmj01NX2UvwrS/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 11/03/2024 22:30, Barry Song wrote: > On Mon, Mar 11, 2024 at 11:01 PM Ryan Roberts wrote: >> >> Now that swap supports storing all mTHP sizes, avoid splitting large >> folios before swap-out. This benefits performance of the swap-out path >> by eliding split_folio_to_list(), which is expensive, and also sets us >> up for swapping in large folios in a future series. >> >> If the folio is partially mapped, we continue to split it since we want >> to avoid the extra IO overhead and storage of writing out pages >> uneccessarily. >> >> Signed-off-by: Ryan Roberts >> --- >> mm/vmscan.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index cf7d4cf47f1a..0ebec99e04c6 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1222,11 +1222,12 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, >> if (!can_split_folio(folio, NULL)) >> goto activate_locked; >> /* >> - * Split folios without a PMD map right >> - * away. Chances are some or all of the >> - * tail pages can be freed without IO. >> + * Split partially mapped folios map >> + * right away. Chances are some or all >> + * of the tail pages can be freed >> + * without IO. >> */ >> - if (!folio_entire_mapcount(folio) && >> + if (!list_empty(&folio->_deferred_list) && > > Hi Ryan, > After reconsidering our previous discussion about PMD-mapped large > folios, I've pondered > the possibility of PMD-mapped Transparent Huge Pages (THPs) being > mapped by multiple > processes. In such a scenario, if one process decides to unmap a > portion of the folio while > others retain the entire mapping, it raises questions about how the > system should handle > this situation. Would the large folio be placed in a deferred list? No - if the large folio is entirely mapped (via PMD), then the folio will not be put on the deferred split list in the first place. See __folio_remove_rmap(): last = (last < ENTIRELY_MAPPED); means that nr will never be incremented above 0. (_nr_pages_mapped is incremented by ENTIRELY_MAPPED for every PMD map). > If > so, splitting it might not > yield benefits, as neither I/O nor swap slots would increase in this > case by not splitting it. > > Regarding PTE-mapped large folios, the absence of an indicator like > "entire_map" makes it > challenging to identify cases where the entire folio is mapped. Thus, > splitting seems to be > the only viable solution in such circumstances. > >> split_folio_to_list(folio, >> folio_list)) >> goto activate_locked; >> -- >> 2.25.1 > > Thanks > Barry