Received-SPF: pass (google.com: domain of linux-kernel+bounces-59895-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Zi Yan <ziy@nvidia.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 "\"Huang, Ying\"" <ying.huang@intel.com>,
 Ryan Roberts <ryan.roberts@arm.com>,
 Andrew Morton <akpm@linux-foundation.org>,
 "\"Matthew Wilcox (Oracle)\"" <willy@infradead.org>,
 David Hildenbrand <david@redhat.com>,
 "\"Yin, Fengwei\"" <fengwei.yin@intel.com>, Yu Zhao <yuzhao@google.com>,
 "\"Kirill A . Shutemov\"" <kirill.shutemov@linux.intel.com>,
 Johannes Weiner <hannes@cmpxchg.org>,
 Baolin Wang <baolin.wang@linux.alibaba.com>,
 Kemeng Shi <shikemeng@huaweicloud.com>,
 Mel Gorman <mgorman@techsingularity.net>,
 Rohan Puri <rohan.puri15@gmail.com>, Mcgrof Chamberlain <mcgrof@kernel.org>,
 Adam Manzanares <a.manzanares@samsung.com>,
 "\"Vishal Moola (Oracle)\"" <vishal.moola@gmail.com>
Subject: Re: [PATCH v3 2/3] mm/compaction: add support for >0 order folio
 memory compaction.
Date: Fri, 09 Feb 2024 14:40:53 -0500
Message-ID: <193E0D43-0084-48AA-91F5-8316A130ADC3@nvidia.com>
In-Reply-To: <5F394663-0AFE-4C12-827C-3A0723863395@nvidia.com>
References: <20240202161554.565023-1-zi.yan@sent.com>
 <20240202161554.565023-3-zi.yan@sent.com>
 <025b7e7c-b17f-47c7-8677-ee36fc6dbc52@suse.cz>
 <5F394663-0AFE-4C12-827C-3A0723863395@nvidia.com>
Content-Type: multipart/signed;
 boundary="=_MailMate_1412060A-F69D-43E1-8BC1-DABAD362161D_=";
 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:
	=?us-ascii?Q?qRR+oGpe4BytcF3oJo8rVhqLKwHbaSI/YDvTfADWl3d864Xj9hHD61DJ/PTy?=
 =?us-ascii?Q?UM5PWDAAuyFoNy5WZ5KHfvIQw7v5XGBCeRhb7HR/DtNoqb8vTW+Dvn6LihLK?=
 =?us-ascii?Q?PBykfAPnvIBP1P6m93rMRkw8Q7l2EIRjJzNh6s1NASPth3A8W1beq//U9sgC?=
 =?us-ascii?Q?gsNncXPCuGcFA4HxJoMPsZBxf+DwIWkNk+wDHy9otGv+gfSsZk96MGZKz4cL?=
 =?us-ascii?Q?YwvdtY5CN4J4hCASV7cOLYb5d08yd8RaGVwDBOB2ieqdTgDtm2TfHBd8hwPu?=
 =?us-ascii?Q?fDszESV8mhg1zSknBadPXYfr1uRsigbSarK+efROPZ8I0w/fO06VES3bikD5?=
 =?us-ascii?Q?PPUNKglWSd65b/g53IBCMLfGri5b4X1QENrlZpV17IiVX2sy/9leKu9A9C8V?=
 =?us-ascii?Q?2cUp2Jk5KpZ8ak5TUBJGtFFEwHCEh7X+ErJJJlauVjoo2GxldHiT3DAWbkiH?=
 =?us-ascii?Q?4IWKoe1nOwm/GUPs8Nbh5WHgir7FwW0XLHGAQoLPK3Ylbyoqqiy5vzG4H9H/?=
 =?us-ascii?Q?WSpD27ZzBvvARud6IORaeZZPJXaznV/mf++BPmu6CjyYd9x1E0heW80Al3XS?=
 =?us-ascii?Q?CGTg/k+mGWisE7GeJhXWnh6SfrgrBoG3oXmNA8wUL+mxCu9tJ4GFN/s5Qpgs?=
 =?us-ascii?Q?Kw0/2zBEo3H+TvqPcPsDNV3he9a5BS8NwYb+9e+gg9Eg2ThMO8TRbWLpiIdq?=
 =?us-ascii?Q?OrkUaNcJ2UwvU2a0AFX6zVfiDxTcIc7uvWsJqjOiXzLzm7co8vFU8Nr9cbJd?=
 =?us-ascii?Q?pIzRaE1ZXt7YxQE3lcct6w8CBMUwO65NHW24YzfmaF6KjNJOwv1w5FFSxw1f?=
 =?us-ascii?Q?b/2bGyWFfYP2oMVPJoaHunebnko0He/9akaaWXBai6/A7iyrGX65x7j/DuTs?=
 =?us-ascii?Q?ouWM6CkGIwdP4DDnxvR76HE9wMlxiPXLAGdIHHCMPUtRHi7qyixZuw16puzl?=
 =?us-ascii?Q?yIYOZd6uIU2tX0UxJ1E9XyCexoSJQOSW405WEklsU9jBqnTkEzZbZM1AfABb?=
 =?us-ascii?Q?TUCq0rmTMvHN42Ysu2t+8KmnpBO3Z55tHY/ffzfn2rJukQPZdSCX/iQaSaar?=
 =?us-ascii?Q?r2wi1HxXOwymWuN9rY0JZgyarvxIcEHdYQkBUEnKThFdIVEk9lApjUJbdnH+?=
 =?us-ascii?Q?b86uFCOIJD4UKknUveJ1uUGkq52FWpGlG/U6IQXpfo+olHt9lm2z9bvx1UeV?=
 =?us-ascii?Q?6dmyM9T8Z9CsmVrn2UTxofGfW5e6o8UuB+0ajQG2dpO0yszFnakFagMAOTvj?=
 =?us-ascii?Q?ETQ8AnXNqd2/jf15jbO6EXZJwJ5LOiEaWj8kgnrWSGSOF6PWL9CuCkUTeq7L?=
 =?us-ascii?Q?D6Nd43fgA5QJkLYCUI11ZlVrK8KhZJMYKNmcgF7pb6nROsTWUms8552tV/EW?=
 =?us-ascii?Q?zDF907rmMFTbNDfY6WffKZw6lshcVt/BmqeOzQkhqmugQ/QZykCSo69DRb9Z?=
 =?us-ascii?Q?rmW7lpy2pSYRV1jSoS1HTvD/r3RsSA70sDY0GIP1lG0tAs24815QeJI7YzE5?=
 =?us-ascii?Q?Sp7EXP8Ubuk/63qBg9F568cQnsrMRZjmP89XpFnM6HOna3c2wUg13w8nlpoG?=
 =?us-ascii?Q?2I0vIHc3zfcP3H3B2hW2zoRlKVPjkUR5BkAHjA98?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 738ec603-99b7-410c-d4cc-08dc29a7086d
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB5744.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2024 19:40:55.8703
 (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: lvyl49MoTTB4yXKQEoSB+EpE2ezX+67FmWXfMJj+ScA8Bi+pLqYUTlmliiDch4bU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7011

--=_MailMate_1412060A-F69D-43E1-8BC1-DABAD362161D_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 9 Feb 2024, at 14:36, Zi Yan wrote:

> On 9 Feb 2024, at 11:37, Vlastimil Babka wrote:
>
>> On 2/2/24 17:15, Zi Yan wrote:
>>> From: Zi Yan <ziy@nvidia.com>
>>>
>>> Before last commit, memory compaction only migrates order-0 folios an=
d
>>> skips >0 order folios. Last commit splits all >0 order folios during
>>> compaction. This commit migrates >0 order folios during compaction by=

>>> keeping isolated free pages at their original size without splitting =
them
>>> into order-0 pages and using them directly during migration process.
>>>
>>> What is different from the prior implementation:
>>> 1. All isolated free pages are kept in a NR_PAGE_ORDERS array of page=

>>>    lists, where each page list stores free pages in the same order.
>>> 2. All free pages are not post_alloc_hook() processed nor buddy pages=
,
>>>    although their orders are stored in first page's private like budd=
y
>>>    pages.
>>> 3. During migration, in new page allocation time (i.e., in
>>>    compaction_alloc()), free pages are then processed by post_alloc_h=
ook().
>>>    When migration fails and a new page is returned (i.e., in
>>>    compaction_free()), free pages are restored by reversing the
>>>    post_alloc_hook() operations using newly added
>>>    free_pages_prepare_fpi_none().
>>>
>>> Step 3 is done for a latter optimization that splitting and/or mergin=
g free
>>> pages during compaction becomes easier.
>>>
>>> Note: without splitting free pages, compaction can end prematurely du=
e to
>>> migration will return -ENOMEM even if there is free pages. This happe=
ns
>>> when no order-0 free page exist and compaction_alloc() return NULL.
>>>
>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>
>> ...
>>
>>>  /*
>>> @@ -1835,9 +1857,17 @@ static struct folio *compaction_alloc(struct f=
olio *src, unsigned long data)
>>>  static void compaction_free(struct folio *dst, unsigned long data)
>>>  {
>>>  	struct compact_control *cc =3D (struct compact_control *)data;
>>> +	int order =3D folio_order(dst);
>>> +	struct page *page =3D &dst->page;
>>> +
>>> +	folio_set_count(dst, 0);
>>
>> We can't change refcount to 0 like this, after it was already set to 1=
 and
>> somebody else might have done get_page_unless_zero(). You need to eith=
er
>> put_page_testzero() and if it's false, consider the page lost, or leav=
e it
>> refcounted and adjust the code to handle both refcounted and non-refco=
unted
>> pages on the lists (the first option is simpler and shouldn't be too b=
ad).
> Got it. Will fix it with the first option. Thanks.

Do you think we should have a WARN or WARN_ONCE if we lose a page here?

--
Best Regards,
Yan, Zi

--=_MailMate_1412060A-F69D-43E1-8BC1-DABAD362161D_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

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

iQJDBAEBCgAtFiEE6rR4j8RuQ2XmaZol4n+egRQHKFQFAmXGf8UPHHppeUBudmlk
aWEuY29tAAoJEOJ/noEUByhUfCkP/RObzF0yMMxUpImoc8bBlSJ770k8EawyvwrX
rxW1Fwgo9ZbnVorKSnDwi6RsnAbogepowwXJB3NReEPq5cwGhxgJQjvr9YL/JVbj
31boDgp9cTtWH3Y09Ojmw+zw/b59rxJnj+ypqiEiVwaeEZ/j0pCYDMu1nF3/SUXB
HnDw5H55aRw9st+dGO+6G6b5b7HHNs65wij2e9eppmKgbcsCGd3U/hPOHGUOB1m1
h19Q4McZUTWRCIBSBGFYxvTm6Mwv3l+fEbPvvyzNHZaoTG5H2IAuBTxqTvMWNcEE
Ka1SCQEABmMdunrYc8hstvkLLMG7+ewwCwlVfZOimJ4Pu+Dh2zmsXQoRqyxwEJvS
nST2rucMym3MB3CWTV/oafs5CwGrsdW+iSD7ZLq6cxGjYrGStXLqOWGIK/+fNCu+
mHUylCVHZubsGAPRPNamAKGnrhv8aJyT+25PF7xs5tZh9j8kfUYiXxYyzkaeCgqS
qDwoSaav7GcST/a5Gy+qNV3ddniLubNLVGF3jtE5NOp5EVhbDBNaDGwEYRlyHarP
BC8l+L1fjoWSTBaGXQ+LFnlyw7x2rdeEVjoalCaO0iX1cKv6JxOITu3Y3JQmTAPX
yrSXmhuV3AnV3SnW4Wax7fjjZeLK8AtUGQmfm9oFNRTlZC3Vmqr3BVWgk7EYWuPA
n3Iv9rHn
=zHN1
-----END PGP SIGNATURE-----

--=_MailMate_1412060A-F69D-43E1-8BC1-DABAD362161D_=--