Received-SPF: pass (google.com: domain of linux-kernel+bounces-142812-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Zi Yan <ziy@nvidia.com>
To: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>, linux-mm@kvack.org,
 Andrew Morton <akpm@linux-foundation.org>,
 Matthew Wilcox <willy@infradead.org>, Ryan Roberts <ryan.roberts@arm.com>,
 Barry Song <21cnbao@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/rmap: do not add fully unmapped large folio to
 deferred split list
Date: Fri, 12 Apr 2024 10:21:20 -0400
Message-ID: <0A4D2CA1-E156-43E9-A1C9-E09E62E760A3@nvidia.com>
In-Reply-To: <CAHbLzkrxR_cpVd_KF1rz9CTVmr4q0KX7T=SseOo8X5u23-5ZJQ@mail.gmail.com>
References: <20240411153232.169560-1-zi.yan@sent.com>
 <ffbbade3-2de5-4bbe-a6e4-49d2ff7a2f0e@redhat.com>
 <CAHbLzkr99knWKZvE4WCWKKr=eezkg89idpE59oo_oBneAQynAA@mail.gmail.com>
 <86722546-1d54-4224-9f31-da4f368cd47e@redhat.com>
 <CAHbLzkrxR_cpVd_KF1rz9CTVmr4q0KX7T=SseOo8X5u23-5ZJQ@mail.gmail.com>
Content-Type: multipart/signed;
 boundary="=_MailMate_8B18A513-34CB-4D0D-B1D9-08E3D10E2574_=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dDE0WkJpUS9rNkNhZ3N3RDR2TkFDcndmWGdJZzk4Z0RzN2tucVlNTVBndmlJ?=
 =?utf-8?B?ZmU0N1UwRDlKaTJnQlcyYWpjc205Yk1mdm95dmtmcUt3d1Z5dFNWaFpOWlhE?=
 =?utf-8?B?SFZpUkF3YUh0VHZucUF4b3Jlemw0NUZBNk8vVG5UQXdaRTc0ZEtsdWlQeG9k?=
 =?utf-8?B?RGdBV1B1RnczcmdUSEVLRWoxRmsvOXJZRTRlWUc4a0cwK3VyWWlQV2FYbVkr?=
 =?utf-8?B?VzJnWHZGRWZ6WEd3NWhkNk05dnFNelIvUW5YNTRFNjRPMFR3OHc2dGFjQ09V?=
 =?utf-8?B?MVQwREd0QWN4dFltVGdLUDE5djUwN2NDWGZSM2VKOERVamVoN1MzbUFOaW5u?=
 =?utf-8?B?a2Nsc05wM0UrcTVDMVY3cWFMMStQdWx1cTRkcXdaUGNlN0E4d0EzZ2FkYWFv?=
 =?utf-8?B?aTJoOWJqWHViS1c0RlFOV3hQVjduSEl3TEN5TzVsaExwM3hXV3JDeXkxY21m?=
 =?utf-8?B?cWpPZ2RhM0tPbERod1Zmeks5K0U2NThtR3RHNWZLWmhqYmh0ZEsybVExeGcy?=
 =?utf-8?B?T1BLdXlUSCt4eDgxMVdaK09tYk5GejY2SE0zelowRkh2RTlhT08wLy9JL2tR?=
 =?utf-8?B?TXlsK2JMRmwzUG8vWWxvZVpONDdHVDVKTjVFNmJhcFpVVk9WY3J5cFZHUnJ6?=
 =?utf-8?B?U0svT0ZVRkdMYVdKckFoeE1KMStBVFJxaEY0TjRIcGtUZTFRaE8zd010Wlg1?=
 =?utf-8?B?cmE3SS9VenNCYjdLbWRqYUxTZWJBYjJiRm9BaERwc2dnbUxQanNoWThlV0Fk?=
 =?utf-8?B?UDVWa3lIWWd4MDduNC91aW9BSHA3eFNJN0tVUEVsZUVUektqNXhDbmJtd3Ir?=
 =?utf-8?B?V0pENGRIVFV2ekRDc0ZSZU1CMWRQb0NnK2FmNi9LMG9naXV4M01CNkZyY1lD?=
 =?utf-8?B?OEJrb2wxWHQ0MUNtTjQ4UHlDSmtmRUtIWlJhbGEvOUpBV3d6ZTcyMWFkOW1M?=
 =?utf-8?B?U3hwd1hzeGdpVHkwck8wZ0t0cGZrWGVaN0RoUERQQlVJL05LR1BkcWM1TVh6?=
 =?utf-8?B?MzRTcUNHaEo3ZnJXclUxOHlDZTZTdklwdmMvOFgyWFlaWTcrTFh6d29LU2tj?=
 =?utf-8?B?dkhhNCsyZlNaMUtYVk0vWWw2cWRaRGRKTkMwaVhhY2JLT0tEMnBhSnRYZkx3?=
 =?utf-8?B?cGxoL2syRGJheEF1UkZ5MkVud3Bkd3MwZWhQcTRLa0J1RU1zQkVKRFdFUnVi?=
 =?utf-8?B?alhUOFpkREkrdnpUcys0UGcxYWNJVlErVzhFOHRtMG5la2t3TlJ6enhSVXp4?=
 =?utf-8?B?ak9mcEJheGVMUzBCbVg3dXVJZEpSMEt6S0pWVjlpNDFrdyt5TVpQV0JPNVla?=
 =?utf-8?B?a1VvSU55TWlkMk5JRkcvZ0hIYkVtZmdiaDZkcVM4RnVBaHdQVThCVnA2Skta?=
 =?utf-8?B?dURRcVFNQ2tQbk4xOVI4bHAvUTRsV25YRUNWdnMzalBESmpsK2JqRVQ1SWV3?=
 =?utf-8?B?WW1lUVBTY1VNZ3MwK0VlOC9YTkhYWDRFcldWV3ZCUkQ2RUlsM0RTZXRSRVVV?=
 =?utf-8?B?K0xhcWp1TVR5MDM0MWREdS9uR05RMW5HZ1IwL3NiMHBZYmhPd3FwY3lpMWd2?=
 =?utf-8?B?MjRjelJEb2l2RnJOdmQ1VDFsSnlhb1d5Ym1VejJlYVB1OFErdjFPK0RNY21G?=
 =?utf-8?B?bHlFMFlSWmNJNjB4ZkxuZVVISFVoOEF4SDlDR05JK09kVW1mK1dPaHIvWTRn?=
 =?utf-8?B?dFpHWEkyR0Z2ekFOMVFxR0w5ZXZpdGdjNWl5Q1paSUJ3NGdZbW11MTVzZ2Zj?=
 =?utf-8?B?ajBMd2FlQ2FaeWRNVmpPOTU3bmkxUWRndS9qRlltK2E0cWJITkFNNnVqMEVV?=
 =?utf-8?B?djZ3akVVUTVDbXNTWWE5Ly9xWVZwaHN0WUw2M0RlcSt0dm4vRnM0MFhDbi9T?=
 =?utf-8?B?RWV3NGloeWNHdzFWc1BNZ3VOL3F6aWM2Rzl3TDJpZ2lqeXcvR3Q4VGtWbkRH?=
 =?utf-8?B?V1RNL2VPM0h0SDhPSzhhMUpkRTVPYUEveC9BcW45dCtYYmc5eThGNUE1OGRJ?=
 =?utf-8?B?QndNSW9UT1EvNEcyVHhaT1dhSUtxd2w1KzEwb2NUTVNpK1I5N2h2S3UrcUpJ?=
 =?utf-8?B?aUd1bXVvVW1MbDBJdkVCRGJiL1dPWEh3NVpyWE1pTVV1N1kwOWp1RGd3cVpH?=
 =?utf-8?Q?Kn0BXhghlTB7HDqaVqfUO7ilE?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69ea6d69-b0ad-4f3b-3928-08dc5afbd4a8
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB5744.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2024 14:21:23.2602
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: S3+kOgtkITrHaZMuNcOD2wJMLCKutQoWJPO2Qdb082WXTvZFm0Fqe2/L+LZ7vrhH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4333

--=_MailMate_8B18A513-34CB-4D0D-B1D9-08E3D10E2574_=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 Apr 2024, at 17:59, Yang Shi wrote:

> On Thu, Apr 11, 2024 at 2:15=E2=80=AFPM David Hildenbrand <david@redhat=
=2Ecom> wrote:
>>
>> On 11.04.24 21:01, Yang Shi wrote:
>>> On Thu, Apr 11, 2024 at 8:46=E2=80=AFAM David Hildenbrand <david@redh=
at.com> wrote:
>>>>
>>>> On 11.04.24 17:32, Zi Yan 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 mapcount be=
fore
>>>>> adding a folio to deferred split list.
>>>>>
>>>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>>>> ---
>>>>>    mm/rmap.c | 9 ++++++---
>>>>>    1 file changed, 6 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>>>> index 2608c40dffad..d599a772e282 100644
>>>>> --- a/mm/rmap.c
>>>>> +++ b/mm/rmap.c
>>>>> @@ -1494,7 +1494,7 @@ static __always_inline void __folio_remove_rm=
ap(struct folio *folio,
>>>>>                enum rmap_level level)
>>>>>    {
>>>>>        atomic_t *mapped =3D &folio->_nr_pages_mapped;
>>>>> -     int last, nr =3D 0, nr_pmdmapped =3D 0;
>>>>> +     int last, nr =3D 0, nr_pmdmapped =3D 0, mapcount =3D 0;
>>>>>        enum node_stat_item idx;
>>>>>
>>>>>        __folio_rmap_sanity_checks(folio, page, nr_pages, level);
>>>>> @@ -1506,7 +1506,8 @@ static __always_inline void __folio_remove_rm=
ap(struct folio *folio,
>>>>>                        break;
>>>>>                }
>>>>>
>>>>> -             atomic_sub(nr_pages, &folio->_large_mapcount);
>>>>> +             mapcount =3D atomic_sub_return(nr_pages,
>>>>> +                                          &folio->_large_mapcount)=
 + 1;
>>>>
>>>> That becomes a new memory barrier on some archs. Rather just re-read=
 it
>>>> below. Re-reading should be fine here.
>>>>
>>>>>                do {
>>>>>                        last =3D atomic_add_negative(-1, &page->_map=
count);
>>>>>                        if (last) {
>>>>> @@ -1554,7 +1555,9 @@ static __always_inline void __folio_remove_rm=
ap(struct folio *folio,
>>>>>                 * is still mapped.
>>>>>                 */
>>>>>                if (folio_test_large(folio) && folio_test_anon(folio=
))
>>>>> -                     if (level =3D=3D RMAP_LEVEL_PTE || nr < nr_pm=
dmapped)
>>>>> +                     if ((level =3D=3D RMAP_LEVEL_PTE &&
>>>>> +                          mapcount !=3D 0) ||
>>>>> +                         (level =3D=3D RMAP_LEVEL_PMD && nr < nr_p=
mdmapped))
>>>>>                                deferred_split_folio(folio);
>>>>>        }
>>>>
>>>> But I do wonder if we really care? Usually the folio will simply get=

>>>> freed afterwards, where we simply remove it from the list.
>>>>
>>>> If it's pinned, we won't be able to free or reclaim, but it's rather=
 a
>>>> corner case ...
>>>>
>>>> Is it really worth the added code? Not convinced.
>>>
>>> It is actually not only an optimization, but also fixed the broken
>>> thp_deferred_split_page counter in /proc/vmstat.
>>>
>>> The counter actually counted the partially unmapped huge pages (so
>>> they are on deferred split queue), but it counts the fully unmapped
>>> mTHP as well now. For example, when a 64K THP is fully unmapped, the
>>> thp_deferred_split_page is not supposed to get inc'ed, but it does
>>> now.
>>>
>>> The counter is also useful for performance analysis, for example,
>>> whether a workload did a lot of partial unmap or not. So fixing the
>>> counter seems worthy. Zi Yan should have mentioned this in the commit=

>>> log.
>>
>> Yes, all that is information that is missing from the patch descriptio=
n.
>> If it's a fix, there should be a "Fixes:".
>>
>> Likely we want to have a folio_large_mapcount() check in the code belo=
w.
>> (I yet have to digest the condition where this happens -- can we have =
an
>> example where we'd use to do the wrong thing and now would do the righ=
t
>> thing as well?)
>
> For example, map 1G memory with 64K mTHP, then unmap the whole 1G or
> some full 64K areas, you will see thp_deferred_split_page increased,
> but it shouldn't.
>
> It looks __folio_remove_rmap() incorrectly detected whether the mTHP
> is fully unmapped or partially unmapped by comparing the number of
> still-mapped subpages to ENTIRELY_MAPPED, which should just work for
> PMD-mappable THP.
>
> However I just realized this problem was kind of workaround'ed by commi=
t:
>
> commit 98046944a1597f3a02b792dbe9665e9943b77f28
> Author: Baolin Wang <baolin.wang@linux.alibaba.com>
> Date:   Fri Mar 29 14:59:33 2024 +0800
>
>     mm: huge_memory: add the missing folio_test_pmd_mappable() for THP
> split statistics
>
>     Now the mTHP can also be split or added into the deferred list, so =
add
>     folio_test_pmd_mappable() validation for PMD mapped THP, to avoid
>     confusion with PMD mapped THP related statistics.
>
>     Link: https://lkml.kernel.org/r/a5341defeef27c9ac7b85c97f030f93e436=
8bbc1.1711694852.git.baolin.wang@linux.alibaba.com
>     Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>     Acked-by: David Hildenbrand <david@redhat.com>
>     Cc: Muchun Song <muchun.song@linux.dev>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> This commit made thp_deferred_split_page didn't count mTHP anymore, it
> also made thp_split_page didn't count mTHP anymore.
>
> However Zi Yan's patch does make the code more robust and we don't
> need to worry about the miscounting issue anymore if we will add
> deferred_split_page and split_page counters for mTHP in the future.

Actually, the patch above does not fix everything. A fully unmapped
PTE-mapped order-9 THP is also added to deferred split list and
counted as THP_DEFERRED_SPLIT_PAGE without my patch, 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().

I will add this information in the next version.

--
Best Regards,
Yan, Zi

--=_MailMate_8B18A513-34CB-4D0D-B1D9-08E3D10E2574_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE6rR4j8RuQ2XmaZol4n+egRQHKFQFAmYZQ2APHHppeUBudmlk
aWEuY29tAAoJEOJ/noEUByhU5w8QAKgu00zj04/v7YMTxzQHxEYKHABIGpeFN2cf
IiA7Sm+JMJMG/sg66ySkSearE+3D4/1XwA25o4FBg9qNZFi7fq6mePNZAoJElIGp
Kyh3k9G67Y9qopCJ87YoUV/OGuKUEY5dydPL7AhT7G0AxZWKyikBMGdHZe8+zMqx
40ZCeLJfx2sRd4DNewl/MI7F0AVP07FgQ47QQ6XiFzh9we0x8y0Ix8S9nCYT2rU5
P4POPPYFB1SXb9ZbsgUnIUSg1VP881GjN4YSC6r841OzqBJPNJqBXR6DCgA92GOE
d7bqectmwKWiVx6S10rttoApt6gi9wqK3bH8dmu/XMAOG3Wyah80mDueOKYa6HZd
OX7lIu993+buovZar7+bzDwYcp4ou7G7RKzo1xqC3YdbyWJWTsZkJj2c6fG6wjQk
pbyuLpwE8Om792UswPNKdmbXByKZhUSFQygvlSFYjmRNZo/1Vp1l+XQV8OtBx3Lp
7BGy0IZtsHgGGUgrE1aIOEjnbMZq+znAUHhMEmh3fhYQ3zRuAek6ZujlpRzUoeB7
hjnix/vV1BHeqVqGECe/QnQztmBT0+TDCygsLmWNreH1OHjLZKjQ1TsMB1m0u8RA
ZYNSB6x/QXd9WV28U9LBdj+JKmz65/y+fK3L1mflm6DVIsIeLLRLF8iASf5npX4a
IAqz2noF
=GyDM
-----END PGP SIGNATURE-----

--=_MailMate_8B18A513-34CB-4D0D-B1D9-08E3D10E2574_=--