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 E6983C4345F for ; Fri, 26 Apr 2024 03:45:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 817456B00A0; Thu, 25 Apr 2024 23:45:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C6E66B00A1; Thu, 25 Apr 2024 23:45:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 668186B00A2; Thu, 25 Apr 2024 23:45:43 -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 4826C6B00A0 for ; Thu, 25 Apr 2024 23:45:43 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EDB61405E0 for ; Fri, 26 Apr 2024 03:45:42 +0000 (UTC) X-FDA: 82050293724.04.F7819BD Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf29.hostedemail.com (Postfix) with ESMTP id 51617120003 for ; Fri, 26 Apr 2024 03:45:41 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AnwnltzI; spf=pass (imf29.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=ioworker0@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=1714103141; 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=8lCcs8nxi939WWR9MSQdpKH4Z/MiLVAwZBmNZPf46as=; b=007tV8CshdHAlMcpanHwL6cQU86/3mOL1P3Er6NSo9PAB0quZ1oO7j7PGsrVJDOsV62QAw abOAoWYTUqvYj1wcNyBbL54iC/i+uGW53XcIJqNNW/bwq6E2Ew+HntqAAu688LJKAfo3hp Jhz9FIgFLPfY7YBFPTSY9aqPL8xilyE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714103141; a=rsa-sha256; cv=none; b=zf2vswyd4Q8ZAKjPYHAxilXw3H+zDZFTM61wJv4DRvMw6/EBjZNUIyCqRMUfgLQDV2IUBd kWEyW9Bo1RnuCAmyF7fVyg8wIePrOp8BDu3zAqBuQn9jVxoZbiW9jFjzlB6EwSMSMSK2Ov T/5WkZVifE85tmpD0zhwz64yT8WjzlE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AnwnltzI; spf=pass (imf29.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-571bddd74c1so1819870a12.0 for ; Thu, 25 Apr 2024 20:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714103140; x=1714707940; 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=8lCcs8nxi939WWR9MSQdpKH4Z/MiLVAwZBmNZPf46as=; b=AnwnltzI21Hb23v2hn1Xmg3nTuCvRzvL6/iWtzjqrGmao7K2/Ya67cciZ2NYrfnHC2 G1yePhqCOgcyCtE4mWfU1rimzjobIygv6pCb6OXeXs6Autwyrb5gnyPIG8IRBX4LGps2 PuG/pfzz2idTHaxAy2Mlllg4UiRmThHMVVMeDAhbn32eI8vTzHdS4eiNDRrULJneJah5 fp0UR5x+ur4Qk4MJuWHsqicgmk503djGvfC+/qHVW1UZ9aeDovzQLiN7Qjsag9Qcotz9 gDWPiLyM237zrY+1pp65laU+kyQEsw1uucYJj+lrTCmsSWNc/ke+d1GfPQCbCi7MJASQ hWlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714103140; x=1714707940; 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=8lCcs8nxi939WWR9MSQdpKH4Z/MiLVAwZBmNZPf46as=; b=w++WTdbyRZzyGQkOG9+THojPCU9Nw3o9AkYL+rQVMNaAO/iSYVx+KNp+JuDBbhQ0Se UxRN9EeJnotqBfyyBZGzkBgjA4kgyCPUtJxEAWvI/lrOT9aAN3d22jLBRyFZUj7yaANa 81tz4p6u0y7bbh6kiNlpx096puQ3eJEereY4s+vf0vmcBX6WFKDR1L+qtHh2Yqez5S7N OyAsTmugu6OQ7t38lZznhos697UcVJnars0tSJxQHU+UBzI2qHHIifrTpW2rLJ03Tvyv vLQerOgok7JSDLhXXGMmOOz+YpFPlxxxP4uR30Lp4xg2G/IHiAVC54QlYVmpeSc8UcgB IRJA== X-Forwarded-Encrypted: i=1; AJvYcCWOo44z6oH89POMoQvJydDsvd15E7+JW/KWgdHkEUhdBVcRT4ik5EdYXMczEwkW7iYX8ETDxEJYrVoZmbRsZnrD1Ok= X-Gm-Message-State: AOJu0YwRhIMX1ISzLZigaFkJwphAmysrRc3Wba6hMfg+GAJ+s0InHzPU yE2SSuYICHZ4Vp61kEzrYVBzAlhmdVGSVvg0A9DWqD+iWW5J6+xZICAr8p0F+r1/YqimoxKmAFD usDF+zlAdO+S4p9Pkmn3f42dbIUA= X-Google-Smtp-Source: AGHT+IGVM8XpR50yzQ/CA6d8mEu/7+uRnmB5Fm71BQdyIRl/Sw81s5gEsqF1EArohpRiATN+qE5qiZwdgaDRTrhjBqQ= X-Received: by 2002:a50:951e:0:b0:56e:2b31:b111 with SMTP id u30-20020a50951e000000b0056e2b31b111mr867490eda.7.1714103139552; Thu, 25 Apr 2024 20:45:39 -0700 (PDT) MIME-Version: 1.0 References: <20240425211136.486184-1-zi.yan@sent.com> In-Reply-To: <20240425211136.486184-1-zi.yan@sent.com> From: Lance Yang Date: Fri, 26 Apr 2024 11:45:25 +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 , Barry Song <21cnbao@gmail.com>, David Hildenbrand , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 51617120003 X-Stat-Signature: i1bkoyqw3uxndro4tspoji1oif9rgtfk X-Rspam-User: X-HE-Tag: 1714103141-171976 X-HE-Meta: U2FsdGVkX18/KcyH/8D1bawKNfeZLJ1Bt/5Eslf3d/QjLFrW7pPh14Qn1LwhjOWDuhImc+h7djR5688zuX2NO3TQWKrdK3ya7rGqTc1kZHu6xu2uJf5ov8lAGuCwizBK85Z+xSkGB4wgTmL9yTd6BlRE0lz+FUDJ0/735UzDYryYLKpvu36GecfxQGPXfnJ2+krBzoT0XyOthNf6XbhZIReOdg9iayafSeH3PF71nN8nwhDuk3ThvzJpXDZzbviE9YDeOKC/+u97MeKNZlaS6Ao+1oGAkrUj48EbAkkOrNKQdwCVivsVoOIwYXgXE/EVy70/Vb4bK+dIQiuWJqDCkJBK9N6RfNp9KzXRpKld6DU6/dGy5H2YUHaMgeI0vzYGPeWWPfelM7Gz/xWnVQWD7SUGzkmQulJQxMAtgqYerWBP2Yp7e+zXbI7RZGXckXSTY0Q2/piTfj1fplD+Rh5BKpG049RKnM0URslVkjNtr7B7HYNdJx60hTu+4kEveo6192QZkdv3LLnFBrN7WBATTWeAwWWLe+X0KqP5Z8k3SClL7jzE5WadVrWEqrPE2NvVXolmrZVac5kUHU8Oz/MS6hLdAHF3Ng2wteleM1CZSQSDFfUycR/OXk9W16/yfo+6zCXRJ3s9N4CiQURF3l+7DZ8xesbjXrFvEcU/qrrutcqsqaMOrlonyRc75q78EdiFWWc07m/C3mYvAHg3+nt467bfrmjGLJD9QYnGFeDDg6/gsAPoXAEGpY39/JNOngOoTd2PWDrTAO29+YkzYpnX56dD1Gmo2gRj09U74hysV1yxFeM0p5PgdKX2Ve+fRlrMD635BCA0vn3ld903mYpBBhWWF9aijb/PgVmVN0zGCNnKRV/dR0dkwG6GdWQuuxK7IVkVyyExsYT74YQWfu7P73HQ2Wz1ZvJEJ2tMY3naSCSacPDkRn/wqZLm9yfEzGsdAFV0ScP6kT6XwfUNaFA NqVKi714 rRQ1vRCHSFQmie5RT5CTwozqsMNYemOkSP4NdxdNmZQ02AZ3lxLo2z5F5pQ+gQJWBJhbtKO92KCodEas77TRRYMBu5g== 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 5:11=E2=80=AFAM Zi Yan wrote: > > From: Zi Yan > > In __folio_remove_rmap(), a large folio is added to deferred split list > if any page in a folio loses its final mapping. But it is possible that > 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 mTHP, > 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 partially > mapped folios -- although the whole folio is fully unmapped stepwise. > > Core-mm now tries batch-unmapping consecutive PTEs of PTE-mapped THPs > where possible starting from commit b06dc281aa99 ("mm/rmap: introduce > folio_remove_rmap_[pte|ptes|pmd]()"). When it happens, a whole PTE-mapped > folio is unmapped in one go and can avoid being added to deferred split > list, reducing the THP_DEFERRED_SPLIT_PAGE noise. But there will still 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., migration= . > > To avoid the unnecessary addition, folio->_nr_pages_mapped is checked > 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 exclude > 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 still > 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_rmap(st= ruct folio *folio, > * page of the folio is unmapped and at least one page > * is still mapped. > */ > - if (folio_test_large(folio) && folio_test_anon(folio)) > - if (level =3D=3D RMAP_LEVEL_PTE || nr < nr_pmdmap= ped) > - deferred_split_folio(folio); > + if (folio_test_large(folio) && folio_test_anon(folio) && > + list_empty(&folio->_deferred_list) && FWIW Perhaps it would achieve the same check, ensuring that at least one page of the folio is unmapped while at least one page remains mapped. + atomic_read(mapped) && nr < folio_nr_pages(folio)) - ((level =3D=3D RMAP_LEVEL_PTE && atomic_read(mapped)) = || - (level =3D=3D RMAP_LEVEL_PMD && nr < nr_pmdmapped))) Thanks, Lance > + ((level =3D=3D RMAP_LEVEL_PTE && atomic_read(mapped))= || > + (level =3D=3D RMAP_LEVEL_PMD && nr < nr_pmdmapped))) > + deferred_split_folio(folio); > } > > /* > > base-commit: 66313c66dd90e8711a8b63fc047ddfc69c53636a > -- > 2.43.0 >