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 65105C4345F for ; Fri, 26 Apr 2024 03:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2C2D6B007B; Thu, 25 Apr 2024 23:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDB676B0082; Thu, 25 Apr 2024 23:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2E546B0083; Thu, 25 Apr 2024 23:28:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9E6D76B007B for ; Thu, 25 Apr 2024 23:28:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 266B31A0688 for ; Fri, 26 Apr 2024 03:28:37 +0000 (UTC) X-FDA: 82050250674.25.CBB8541 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by imf17.hostedemail.com (Postfix) with ESMTP id 8F1CD4000C for ; Fri, 26 Apr 2024 03:28:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V4to0JeO; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714102115; 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:dkim-signature; bh=CyHxC41lHfusFiTgDcGJmDgmhY96MrkI4VAWat9lk0A=; b=MEj/z0dJPfuZMetXoosif0taXxyT25Cw+OkVSmNfSEQ8PoPw86K8LxhReGhCSrxGzmD0hK etdDntUHeIPbsn5VAP9cSV24OYC2KksECDXC8yhJ84YYOQALBAqxCFcp5sKUPry/CX8Z+G Mq94arHSU7yxfJa95rC9Mg4xBVcQAT4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714102115; a=rsa-sha256; cv=none; b=aXTQNRx5NYnRiCySoln2hWm28QN7ijdWcNN1nB7jTAnzu/HI3/b+fh4wPzKqM18ykf8EKg hI8Oxkmsckhpuqlyf40yblhMv7tVOkOq5SjoTLYXbQqnIPDRo5ECjfWvXyhb10m5Ov+EKy NZ9J6hj52BARYlR3+HTg5PyJXsFWayM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V4to0JeO; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-4affeacaff9so393215e0c.3 for ; Thu, 25 Apr 2024 20:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714102114; x=1714706914; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CyHxC41lHfusFiTgDcGJmDgmhY96MrkI4VAWat9lk0A=; b=V4to0JeOAycxA6/mxtgBEuvEJ7J6bG++UC8RsruFKowJvfzhLFXHfta5qLIzhg9kj8 /Xgu/fUD/d/hjxwc7GKxrTcH64j8/fmOQscHlgLT/MF8UcAXy1wsL1HB3GE6VtCI60IZ 16y2uhQ3aE/gQrRu+1KnqRJSOJVmCG887Ze24tFoH0lGg53OzZ80y9bKbnzlCVBw3nGo 3GcVps6EaVUbxEbUnRBiRsSYV2RjD9TNoiZ64VsoOXfEt7JL3/NrZEm1u9DXoSDxkoZs WtwhYQv8KxqigQKEETB0Irb4f+xKAXxdpKezfT8YQ6dLri6s6YDXBpKKWSJW7pRpzgkD K4ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714102114; x=1714706914; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CyHxC41lHfusFiTgDcGJmDgmhY96MrkI4VAWat9lk0A=; b=imWx0H7W/kWJlPHP7Kg7dvAdV/rODEb6gB/MmZUIcDdE+ED7pJD4WKdF6qK5Y/IfAX vC83yZICXvdsm0Cz40gARRSsJdviQP67/dm+ZwalR8oGmcf/guRFnIQDgyJTehVubttn P67qjwsbPrnR6Nysy3Okeb6aNxVDo7sk8bDo+2Yp3xG9gpcxPhzzfvzzs7lrDMdT8ZIw OeaM4nN4tFL4+fYwAgghFdlQzhlmycd0J3/+OuGx2XxuN1vFImyGCRYspPsI0dWPhLXb AQ2M+2G7xCDFjSZBUeoY9ucYM+cqFxxZGIItdTBnwV0vZVZ8ZuaeMu3O9lxPh9OCtpAL sSOg== X-Forwarded-Encrypted: i=1; AJvYcCXScHWiloJ5JFU4UE4CTudi2C1+WHjqOL5cla24orenCyxQdPArlZ0doTftT0C0ZLmfFdytpSjMIMWvEYoJZ/rsYAs= X-Gm-Message-State: AOJu0YzVOr0ETfd7XcdJdC6PsFo8ZbnPr0sAAkvAMrjbLlBp+oSgJk0W IohSsIy2cO4sUuRvyepmX1mp0Ik4RnRB3TisBkB0h2kffvp8f/aMThUY7bAvVNeuRbk2Amtw2gl 5Kq975wyFnldCfL9DqKZaxbcyEY0= X-Google-Smtp-Source: AGHT+IHHV9qmt/bnW4eu4JuN4hMYG1Vu/q/MSh/GsaDPNA2tdn/uecOBpGwt+YPK2O0cHKjTnBIqVgI8Ku77KnE4XGY= X-Received: by 2002:a05:6122:3d15:b0:4d4:126b:2c8 with SMTP id ga21-20020a0561223d1500b004d4126b02c8mr1537871vkb.9.1714102114546; Thu, 25 Apr 2024 20:28:34 -0700 (PDT) MIME-Version: 1.0 References: <20240425211136.486184-1-zi.yan@sent.com> <6C31DF81-94FB-4D09-A3B8-0CED2AD8EDDB@nvidia.com> <730660D2-E1BA-4A2E-B99C-2F160F9D9A9B@nvidia.com> In-Reply-To: <730660D2-E1BA-4A2E-B99C-2F160F9D9A9B@nvidia.com> From: Barry Song <21cnbao@gmail.com> Date: Fri, 26 Apr 2024 11:28:23 +0800 Message-ID: Subject: Re: [PATCH v4] mm/rmap: do not add fully unmapped large folio to deferred split list To: Zi Yan Cc: Andrew Morton , linux-mm@kvack.org, "Matthew Wilcox (Oracle)" , Yang Shi , Ryan Roberts , David Hildenbrand , Lance Yang , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8F1CD4000C X-Rspam-User: X-Stat-Signature: s56tjyetbsppocoa19f948qom4ryiiq7 X-HE-Tag: 1714102115-92360 X-HE-Meta: U2FsdGVkX18UJVTGF5lQNwmKCBk+/Ltq09RbtNgGqummQ3dcyw+1/rX78dR96ZO6R/faBwbfmKcp3MvT17dKHUKYeG3dgAPfzPZvwk97aMJ0iBDTo9EPL+WwXCu4KXVaSLEA8nYC9w6/KAA4/YaF8h310KDGaHlRlTEzNB8Gv+pcKPPdx5quV7HlN5giVw1d4y0DtPFoSWwbtw7C7bpE5J2IA+JCq7ifgn+30rvIuQVa16x6iV1mQpd2VRKqBp0vkWGHcRPnWsq/fBSNZzdQk0CVTSTeONJ3s9Ehe7F2FrSgcw4IXc8jI9L5t4Nx6X/oqi3QmvMmpQr5Zt867A3WCY9Yk6UK+5eOnFChTs+m9Oxpzm1CwXHAILsbTDhJA1spq8EIgwXjx8+PTYXX3qW9QVbyPKH26Ihvq7QLlcBBcpcb8PdtgWWe3pB0h9GWC8SC6nups79fI/GvP2/UBz/c229KTTd7S8QaGmCUZpgbb6pyJ746oBUXa/ljp+TaVmLk4uf5gVPI6px4DTQDVwfoVjqcJISo3XzUlVG6s4miZaRMqWRf1SrNbg6YRyNrAKxhh9yT2mVuB+y4MWlWBL3WqKWR0juhVVouSm9fGB11/GpevViFFsb9QjT0rZmt7fNqLTrfOEV5a0yO4k0dKrKtZEj/W26LU8cFJ+ONluX3qyAMHE9BxM3dXwA00ZKEUFzdEhNyZ9fZLVfQ2+di2AY214pfnk01Rpq4SXOOXy5Klif0rTcuC5Y5Ok1AEnZ6PgoFxRcfMpdpnKKCgZigG1hXwDQ9InXutg52cWs5JF8PZcimn6HGkkmBXYl19HHMWDDSKuaHSdNSubS6FTAjzSm3DkeEZwd41JhLrlBpo8MLwe2GeaqDFRfcc6eQIYXuTa122gfoJNttZAEV6XQ8G1WW4DywlUiAQiryX370ZzEWfrZ9BEX5FVLhS5fasv7NDckQKkdCMJqa5AsF80KH/pa 2A77YpYA XrWQypiMR36n4NMRY6neSQ8pFdup1Po4HB1gZ 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 Fri, Apr 26, 2024 at 10:50=E2=80=AFAM Zi Yan wrote: > > On 25 Apr 2024, at 22:23, Barry Song wrote: > > > On Fri, Apr 26, 2024 at 9:55=E2=80=AFAM Zi Yan wrote: > >> > >> On 25 Apr 2024, at 21:45, Barry Song wrote: > >> > >>> On Fri, Apr 26, 2024 at 5:11=E2=80=AFAM Zi Yan wrot= e: > >>>> > >>>> From: Zi Yan > >>>> > >>>> In __folio_remove_rmap(), a large folio is added to deferred split l= ist > >>>> if any page in a folio loses its final mapping. But it is possible t= hat > >>>> the folio is fully unmapped and adding it to deferred split list is > >>>> unnecessary. > >>>> > >>>> For PMD-mapped THPs, that was not really an issue, because removing = the > >>>> last PMD mapping in the absence of PTE mappings would not have added= the > >>>> folio to the deferred split queue. > >>>> > >>>> However, for PTE-mapped THPs, which are now more prominent due to mT= HP, > >>>> they are always added to the deferred split queue. One side effect > >>>> is that the THP_DEFERRED_SPLIT_PAGE stat for a PTE-mapped folio can = be > >>>> unintentionally increased, making it look like there are many partia= lly > >>>> mapped folios -- although the whole folio is fully unmapped stepwise= . > >>>> > >>>> Core-mm now tries batch-unmapping consecutive PTEs of PTE-mapped THP= s > >>>> where possible starting from commit b06dc281aa99 ("mm/rmap: introduc= e > >>>> folio_remove_rmap_[pte|ptes|pmd]()"). When it happens, a whole PTE-m= apped > >>>> folio is unmapped in one go and can avoid being added to deferred sp= lit > >>>> list, reducing the THP_DEFERRED_SPLIT_PAGE noise. But there will sti= ll be > >>>> noise when we cannot batch-unmap a complete PTE-mapped folio in one = go > >>>> -- or where this type of batching is not implemented yet, e.g., migr= ation. > >>>> > >>>> To avoid the unnecessary addition, folio->_nr_pages_mapped is checke= d > >>>> to tell if the whole folio is unmapped. If the folio is already on > >>>> deferred split list, it will be skipped, too. > >>>> > >>>> Note: commit 98046944a159 ("mm: huge_memory: add the missing > >>>> folio_test_pmd_mappable() for THP split statistics") tried to exclud= e > >>>> mTHP deferred split stats from THP_DEFERRED_SPLIT_PAGE, but it does = not > >>>> fix the above issue. A fully unmapped PTE-mapped order-9 THP was sti= ll > >>>> added to deferred split list and counted as THP_DEFERRED_SPLIT_PAGE, > >>>> since nr is 512 (non zero), level is RMAP_LEVEL_PTE, and inside > >>>> deferred_split_folio() the order-9 folio is folio_test_pmd_mappable(= ). > >>>> > >>>> Signed-off-by: Zi Yan > >>>> Reviewed-by: Yang Shi > >>>> --- > >>>> mm/rmap.c | 8 +++++--- > >>>> 1 file changed, 5 insertions(+), 3 deletions(-) > >>>> > >>>> diff --git a/mm/rmap.c b/mm/rmap.c > >>>> index a7913a454028..220ad8a83589 100644 > >>>> --- a/mm/rmap.c > >>>> +++ b/mm/rmap.c > >>>> @@ -1553,9 +1553,11 @@ static __always_inline void __folio_remove_rm= ap(struct folio *folio, > >>>> * page of the folio is unmapped and at least one pa= ge > >>>> * is still mapped. > >>>> */ > >>>> - if (folio_test_large(folio) && folio_test_anon(folio= )) > >>>> - if (level =3D=3D RMAP_LEVEL_PTE || nr < nr_p= mdmapped) > >>>> - deferred_split_folio(folio); > >>>> + if (folio_test_large(folio) && folio_test_anon(folio= ) && > >>>> + list_empty(&folio->_deferred_list) && > >>>> + ((level =3D=3D RMAP_LEVEL_PTE && atomic_read(map= ped)) || > >>>> + (level =3D=3D RMAP_LEVEL_PMD && nr < nr_pmdmapp= ed))) > >>>> + deferred_split_folio(folio); > >>> > >>> Hi Zi Yan, > >>> in case a mTHP is mapped by two processed (forked but not CoW yet), i= f we > >>> unmap the whole folio by pte level in one process only, are we still = adding this > >>> folio into deferred list? > >> > >> No. Because the mTHP is still fully mapped by the other process. In te= rms of code, > >> nr will be 0 in that case and this if condition is skipped. nr is only= increased > >> from 0 when one of the subpages in the mTHP has no mapping, namely pag= e->_mapcount > >> becomes negative and last is true in the case RMAP_LEVEL_PTE. > > > > Ok. i see, so "last" won't be true? > > > > case RMAP_LEVEL_PTE: > > do { > > last =3D atomic_add_negative(-1, &page->_mapcount); > > if (last && folio_test_large(folio)) { > > last =3D atomic_dec_return_relaxed(mapped); > > last =3D (last < ENTIRELY_MAPPED); > > } > > > > if (last) > > nr++; > > } while (page++, --nr_pages > 0); > > break; > > Right, because for every subpage its corresponding > last =3D atomic_add_negative(-1, &page->_mapcount); is not true after the= unmapping.2 if a mTHP is mapped only by one process, and we unmap it entirely, we will get nr > 0, then we are executing adding it into deferred_list? so it seems atomic_read(mapped) is preventing this case from adding deferred_list? I wonder if it is possible to fixup nr to 0 from the first place? for example /* we are doing an entire unmapping */ if (page=3D=3D&folio->page && nr_pages =3D=3D folio_nr_pages(folio)) ... > > > -- > Best Regards, > Yan, Zi