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 077CFEB64DC for ; Tue, 18 Jul 2023 08:58:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B99F8D0002; Tue, 18 Jul 2023 04:58:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8435C8D0001; Tue, 18 Jul 2023 04:58:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E2DC8D0002; Tue, 18 Jul 2023 04:58:12 -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 5A72A8D0001 for ; Tue, 18 Jul 2023 04:58:12 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0D067B0A0A for ; Tue, 18 Jul 2023 08:58:12 +0000 (UTC) X-FDA: 81024130824.21.5BEA261 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf15.hostedemail.com (Postfix) with ESMTP id 0FB27A000D for ; Tue, 18 Jul 2023 08:58:09 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.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=1689670690; 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=Xesw3eCiqVKRy6fYSoiULEZW4CGP4ert4rqS2G8jQO8=; b=WsmTgTHW2JbP00XNwP8dIPlWXMBI1CBl73J0oy9DUZtMMh5c7+thKo4WSsDg87yTcB8Bbo 6e937zvZC2OGel6Jpg+HnY8XTdngo8etbwzHbsLwM4MoZ2ZRPwtw7Jm2Bs6Y9DX8VveHaY hDcZ1klU2tog5N06eNUM2ID0/ouO0Vo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689670690; a=rsa-sha256; cv=none; b=keUNT7rTDri0dIGG1elug/cxN4Env6GJY2tC7EBhQgJzOp+reMQXbAxQWedktjQxgJUorp AyikLlBoZ3Vy28Gt8d8wf633DJLcNfl4kxPj4hsqCHY7FqxBqA03ujttyL+J/dRzr1+cx3 wJwkBPS2ltzk/qOf/aOf4YeydNQ/PZA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.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 689522F4; Tue, 18 Jul 2023 01:58:52 -0700 (PDT) Received: from [10.1.34.52] (C02Z41KALVDN.cambridge.arm.com [10.1.34.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 88D0C3F67D; Tue, 18 Jul 2023 01:58:07 -0700 (PDT) Message-ID: <7319a1aa-7c72-82e9-f26d-eeccb6fdf35b@arm.com> Date: Tue, 18 Jul 2023 09:58:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v1 1/3] mm: Allow deferred splitting of arbitrary large anon folios To: David Hildenbrand , Andrew Morton , Matthew Wilcox , Yin Fengwei , Yu Zhao , Yang Shi , "Huang, Ying" , Zi Yan Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230717143110.260162-1-ryan.roberts@arm.com> <20230717143110.260162-2-ryan.roberts@arm.com> <90b406af-9db4-b668-a7a0-e574e104c84c@redhat.com> <028c5f5b-b67c-9ccc-bc06-468f47362999@arm.com> <0250a2d7-c79b-0e0f-8161-bf475daf1c82@redhat.com> From: Ryan Roberts In-Reply-To: <0250a2d7-c79b-0e0f-8161-bf475daf1c82@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: cefcg1mf3zkwt878q7g918nwczpkxqhr X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0FB27A000D X-Rspam-User: X-HE-Tag: 1689670689-165829 X-HE-Meta: U2FsdGVkX1850rDxiH+uVHUl81flXuyxpcUNo4Ysl/Ikgxu9AV32ISTdn+fxGzmkrbwN677MWi8H2R2bNJ6Ja0aOguYw9LEXrMy3t/gSOYAPTS20YppyGOWQNr19y4Fp02pZ1mmw8tMEJEhX8RjYem/Nem9p5C55DbjI3/QlxtXXXuFP9h5ANfHjWl3TjqsNWPm3eTZgjruw+zFk0eHomdgzxAJ0ufZanJWAY1897sy1MzzAUGkjySowrIA5ZJRgMcG0QiFSpfq4dHzr9h4n/iC4bGDAQj+o1hMw42u6AEGz6N+yjgcdTrwXei2rFqokN+69XOZEGfrM3/+JOSYeUtPHskjSDbUor6zpA2h/6/3EQHjRtSJEFWR1jOe/M0u3W8ERxt/wI/iRH1J2lzmQKhnDOJydNFlCkrfsGic/+D3A6OPzHiG43t2VRpze/r4GnQuZQl+fJFfbNECkLY7+Z0+6JY1G3hq27nxvSshAM/hvcHY6BASXHQ3jwvj1+rS3NqmDRNfIsuocmDvp6iry9nNjK40obBqzEXmLWlad6zjnVeani3xw+du4TS3xHJGpQMtVEGykaR7aVjuw7cUY7Z6V056czbIFNto9afWJAMEE6z4LvNxuS+tBgfq1fKrXevli23POCU5Q5cAro0rvK/BGbHkH0MYxP4iOSGi1MCAELOV1IV6Fr44/aEJncjcz7CXPxfWu8iC2p7CavjAWkiUbeQpbMpodV+m5/Pvv0UqpUE45gwfcF3WHqBsOVnkgfS+CmUQPhDI672F067D5DHWP/EFRYu/sEjpcvvVyOb6cms4j2314fDV3CIKjwe/hpCuJJF7sC/qk32s0AGE+H0VI1EznLu1BEc3Nm/qp9zH+Yv2Op4DRMNZjUqBW/s4Mu8ZZaT2kBWOikiLEN3TNU1pznQJhuTditU0AdvaphM+GOnFEYJd3fOoVzV2zls5RYbDbhkPU89Ss2b4kCtN YHQqFqpU DnqhNwzsZ8H6MtsnLBrxHBeBtfnqeMPqjBzqZlL1N7G3Jrf0fs6sgUczQzX8nmP9eGU7WBEo+ChcEZh6k9sA/qE9Lcb3uqExTATgDcpLmpw/Yw/cCz3044z7SHS/2YKUMDa3lF49v3lBy3EhlSFfZ55cRZ1oSeab7WkOeoCx/OgbYjzPkZjQ67Cz9u2jnwsobfPja6Q42C0kcesFBDM/ft/0bBg== 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: On 17/07/2023 17:48, David Hildenbrand wrote: > On 17.07.23 18:01, Ryan Roberts wrote: >> On 17/07/2023 16:42, David Hildenbrand wrote: >>> On 17.07.23 16:31, Ryan Roberts wrote: >>>> In preparation for the introduction of large folios for anonymous >>>> memory, we would like to be able to split them when they have unmapped >>>> subpages, in order to free those unused pages under memory pressure. So >>>> remove the artificial requirement that the large folio needed to be at >>>> least PMD-sized. >>>> >>>> Signed-off-by: Ryan Roberts >>>> Reviewed-by: Yu Zhao >>>> Reviewed-by: Yin Fengwei >>>> --- >>>>    mm/rmap.c | 2 +- >>>>    1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/mm/rmap.c b/mm/rmap.c >>>> index 0c0d8857dfce..2baf57d65c23 100644 >>>> --- a/mm/rmap.c >>>> +++ b/mm/rmap.c >>>> @@ -1430,7 +1430,7 @@ void page_remove_rmap(struct page *page, struct >>>> vm_area_struct *vma, >>>>             * page of the folio is unmapped and at least one page >>>>             * is still mapped. >>>>             */ >>>> -        if (folio_test_pmd_mappable(folio) && folio_test_anon(folio)) >>>> +        if (folio_test_large(folio) && folio_test_anon(folio)) >>>>                if (!compound || nr < nr_pmdmapped) >>>>                    deferred_split_folio(folio); >>> >>> !compound will always be true I guess, so nr_pmdmapped == 0 (which will always >>> be the case) will be ignored. >> >> I don't follow why !compound will always be true. This function is >> page_remove_rmap() (not folio_remove_rmap_range() which I add in a later patch). >> page_remove_rmap() can work on pmd-mapped pages where compound=true is passed in. > > I was talking about the folio_test_pmd_mappable() -> folio_test_large() change. > For folio_test_large() && !folio_test_pmd_mappable() I expect that we'll never > pass in "compound=true". > Sorry David, I've been staring at the code and your comment, and I still don't understand your point. I assumed you were trying to say that compound is always false and therefore "if (!compound || nr < nr_pmdmapped)" can be removed? But its not the case that compound is always false; it will be true when called to remove a pmd-mapped compound page. What change are you suggesting, exactly?