Received-SPF: pass (google.com: domain of linux-kernel+bounces-157788-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240424211031.475756-1-zi.yan@sent.com>
In-Reply-To: <20240424211031.475756-1-zi.yan@sent.com>
From: Yang Shi <shy828301@gmail.com>
Date: Wed, 24 Apr 2024 15:32:11 -0700
Message-ID: <CAHbLzkq61sTeRxU23gg3kMNBunxXH3GpkL6D56xcaepsDzFCJA@mail.gmail.com>
Subject: Re: [PATCH v2] mm/rmap: do not add fully unmapped large folio to
 deferred split list
To: Zi Yan <ziy@nvidia.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, 
	"Matthew Wilcox (Oracle)" <willy@infradead.org>, Ryan Roberts <ryan.roberts@arm.com>, 
	Barry Song <21cnbao@gmail.com>, David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 24, 2024 at 2:10=E2=80=AFPM Zi Yan <zi.yan@sent.com> wrote:
>
> From: Zi Yan <ziy@nvidia.com>
>
> In __folio_remove_rmap(), a large folio is added to deferred split list
> if any page in a folio loses its final mapping. It is possible that
> the folio is unmapped fully, but it is unnecessary to add the folio
> to deferred split list at all. Fix it by checking folio->_nr_pages_mapped
> before adding a folio to deferred split list. If the folio is already
> on the deferred split list, it will be skipped.
>
> 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 everything. A fully unmapped PTE-mapped order-9 THP was also 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(). However, this miscount
> was present even earlier due to implementation, since PTEs are unmapped
> individually and first PTE unmapping adds the THP into the deferred split
> list.

Shall you mention the miscounting for mTHP too? There is another patch
series adding the counter support for mTHP.

>
> With commit b06dc281aa99 ("mm/rmap: introduce
> folio_remove_rmap_[pte|ptes|pmd]()"), kernel is able to unmap PTE-mapped
> folios in one shot without causing the miscount, hence this patch.
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
>  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) &&

Do we really need this check? deferred_split_folio() does the same
check too. Bailing out earlier sounds ok too, but there may not be too
much gain.

> +                   ((level =3D=3D RMAP_LEVEL_PTE && atomic_read(mapped))=
 ||
> +                    (level =3D=3D RMAP_LEVEL_PMD && nr < nr_pmdmapped)))

IIUC, this line is used to cover the case which has both partial
PTE-mapping and PMD-mapping, then PMD mapping is unmapped fully. IIRC
this case was not handled correctly before, the THP actually skipped
deferred split queue. If so please add some description in the commit
log.

Otherwise the patch looks good to me. Reviewed-by: Yang Shi
<shy828301@gmail.com>

> +                       deferred_split_folio(folio);
>         }
>
>         /*
>
> base-commit: 2541ee5668b019c486dd3e815114130e35c1495d
> --
> 2.43.0
>