Received-SPF: pass (google.com: domain of linux-kernel+bounces-59910-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
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 3/3] mm/compaction: optimize >0 order folio compaction
 with free page split.
Date: Fri, 09 Feb 2024 14:57:05 -0500
Message-ID: <8E042D2A-B4B1-4538-946C-A63A0DB64FE0@nvidia.com>
In-Reply-To: <84dfedc4-a0a2-4e02-9be4-2cffc6e9fd06@suse.cz>
References: <20240202161554.565023-1-zi.yan@sent.com>
 <20240202161554.565023-4-zi.yan@sent.com>
 <84dfedc4-a0a2-4e02-9be4-2cffc6e9fd06@suse.cz>
Content-Type: multipart/signed;
 boundary="=_MailMate_BD14FE1B-E5CC-48E5-91A1-105DB631D11D_=";
 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?6dxJCiV73tF7zB63xtBc+Hm9F1EC0t2zZxxBcjlNzq6qJ8+TKHXGpq+8Ar1/?=
 =?us-ascii?Q?Ud7G+PZUzHlwLGCPPPLiM7BqXAfZzJrVnyzrcj03KZbfbQ1jmRuYA+y0t6Td?=
 =?us-ascii?Q?/EjnOVzxYS+77Nw1mcI3hQ2Xi0fQ0/zWkX55JLPUTD5E9WevTn5eorcE8pGr?=
 =?us-ascii?Q?G083NF97wbeTe3+dj6PhRo2dPV2O9HDh2lLyRozrhoAYQvw/JaE4SbE/fHWm?=
 =?us-ascii?Q?06Lz+Ores5r3NjRJcBqTvtR+7YJF4Q+hxCiNydakuVBLmeNEp4V55xDsm6a3?=
 =?us-ascii?Q?TE/F4gd7yve6kl1DbIcYTkFR728K0ATkkGXKvK8IkvW/6DdhzteaMYKH8hy+?=
 =?us-ascii?Q?IYo2rvhpyuoQ13CeBRBXdM2vvAJqiY00HjQb/yLaXfWDnNfGjv+6Iv9XJYmZ?=
 =?us-ascii?Q?ilrXbVDbzOdX7OvwDEsC475zmpXqANkfednC9Yy7+ip9kU/7S4o4A1Wccwve?=
 =?us-ascii?Q?1PRO24NE+KWcqxLXb62maFC4jUdHsRDJ07hAAJ8eI8r8O7wEQI+imk/zkH6y?=
 =?us-ascii?Q?bN+g4AcEz43Spp3+Ko0nFxZKRMvx2WcVbDHWTElz+dVr3oA3KkHm0IRyVY6t?=
 =?us-ascii?Q?4tAUufbvTgDnwGJW0Yqlwb267WW7YY3ElYGgVVKowmWJjOER2QAglEiC/a0j?=
 =?us-ascii?Q?d/kIipQu4vG0QQKGuR+F6CJ2P9PvOKgLfD6ZH1gDz4sDQv2mmxKkNUnr8qFM?=
 =?us-ascii?Q?DejWNwymEjMeg7+qS1UH1+3O3lNIZcDWMIFiIzB1+hdpQCGNQnp3P1650Psx?=
 =?us-ascii?Q?GFILmggmumtDCQ8m/Yy9XavtqxWshqzVogC3Uv0scjpnEuih5AMuant34uwT?=
 =?us-ascii?Q?+pUq6Ax5v7Gp891K4dQCay/v36zK0iM7tBWEbeCA6V4YZiAaWTIwgs/BvjxX?=
 =?us-ascii?Q?kokzENCxLAb/MwhaBzE9zffE/EzzmJMhudUeNpaMJ/XnqqDSxzwMhj1nY/5c?=
 =?us-ascii?Q?efsDYnsLGlvuuMR4kOPObEtiagB6HlWNtuz4MOKnQrNpq55sW1J/EshtQau1?=
 =?us-ascii?Q?HVb51bdRC5AeC40thGEcVOdUwKvecpUzbI4hqoMafHN/vHWPT/w7uzJDtkME?=
 =?us-ascii?Q?MNY0ZhdWQI0RM+XBoDFKcRR4F9e52DpfsQqr9g2T4fTz7mvOGUXHInS5GeKU?=
 =?us-ascii?Q?d+OHQRaKMID3C7iMCwZd9wesIlzF641mTQuKD8VJe6ZBGYxwsB8VsritRKuq?=
 =?us-ascii?Q?g+tf0UZK2twh9LMZLktQOu2uAPrmPwFpGgjQHfXTh6SK5gfDSy0z1KWGPEt7?=
 =?us-ascii?Q?NIEGdEFBof5FWfNor4ATTNDGvJE1IvTeKsknz9HttODNiXJFMzROQBS3Yb+C?=
 =?us-ascii?Q?DyJZAO0FonjL0HvBsNehOkTr06vegjR9wIuUr0x0wPA5PVUceoKOcISoq1i6?=
 =?us-ascii?Q?de3/UDK2RYJQiJj+3+XP7SdoJLrZW/w7Yj6qwh0sKWTdZBXA5Vb76y4+7BDS?=
 =?us-ascii?Q?EsiENkebEejZ4M9ec8OrN0gK1YU2+nGEgQHlhkmWoSdzomfdS+yYSkdWVUHX?=
 =?us-ascii?Q?CkxktpoKNOjwGQuii1yrFJh10dNRaHbSii+8EC9Er/G209NADZe64hb9oaeI?=
 =?us-ascii?Q?wk6eRFM6yWVKLdzGId94CS90GIxVmTm9XyX/9rmk?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5112e0a-0a4e-4f9a-a545-08dc29a94bc2
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:57:07.7979
 (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: M6xYthyBIqSIhiy3cgJjFcuwxjC8mIiBZU9gqI3YcKf25UuAJ4LSRpxEuWnZf80d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5132

--=_MailMate_BD14FE1B-E5CC-48E5-91A1-105DB631D11D_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 9 Feb 2024, at 13:43, Vlastimil Babka wrote:

> On 2/2/24 17:15, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> During migration in a memory compaction, free pages are placed in an a=
rray
>> of page lists based on their order. But the desired free page order (i=
=2Ee.,
>> the order of a source page) might not be always present, thus leading =
to
>> migration failures and premature compaction termination. Split a high
>> order free pages when source migration page has a lower order to incre=
ase
>> migration successful rate.
>>
>> Note: merging free pages when a migration fails and a lower order free=

>> page is returned via compaction_free() is possible, but there is too m=
uch
>> work. Since the free pages are not buddy pages, it is hard to identify=

>> these free pages using existing PFN-based page merging algorithm.
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>>  mm/compaction.c | 37 ++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 58a4e3fb72ec..fa9993c8a389 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1832,9 +1832,43 @@ static struct folio *compaction_alloc(struct fo=
lio *src, unsigned long data)
>>  	struct compact_control *cc =3D (struct compact_control *)data;
>>  	struct folio *dst;
>>  	int order =3D folio_order(src);
>> +	bool has_isolated_pages =3D false;
>>
>> +again:
>>  	if (!cc->freepages[order].nr_pages) {
>> -		isolate_freepages(cc);
>> +		int i;
>> +
>> +		for (i =3D order + 1; i < NR_PAGE_ORDERS; i++) {
>
> You could probably just start with a loop that finds the start_order (a=
nd do
> the isolate_freepages() attempt if there's none) and then handle the re=
st
> outside of the loop. No need to separately handle the case where you ha=
ve
> the exact order available?
Like this?

if (list_empty(&cc->freepages[order].pages)) {
        int start_order;

        for (start_order =3D order + 1; start_order < NR_PAGE_ORDERS;
             start_order++)
                if (!list_empty(&cc->freepages[start_order].pages))
                        break;

        /* no free pages in the list */
        if (start_order =3D=3D NR_PAGE_ORDERS) {
                if (!has_isolated_pages) {
                        isolate_freepages(cc);
                        has_isolated_pages =3D true;
                        goto again;
                } else
                        return NULL;
        }

        struct page *freepage =3D
                list_first_entry(&cc->freepages[start_order].pages,
                                 struct page, lru);

        unsigned long size =3D 1 << start_order;

        list_del(&freepage->lru);

        while (start_order > order) {
                start_order--;
                size >>=3D 1;

                list_add(&freepage[size].lru,
                        &cc->freepages[start_order].pages);
                set_page_private(&freepage[size], start_order);
        }
        dst =3D (struct folio *)freepage;
        goto done;
}

>
>> +			if (cc->freepages[i].nr_pages) {
>> +				struct page *freepage =3D
>> +					list_first_entry(&cc->freepages[i].pages,
>> +							 struct page, lru);
>> +
>> +				int start_order =3D i;
>> +				unsigned long size =3D 1 << start_order;
>> +
>> +				list_del(&freepage->lru);
>> +				cc->freepages[i].nr_pages--;
>> +
>> +				while (start_order > order) {
>
> With exact order available this while loop will just be skipped and tha=
t's
> all the difference to it?
>
>> +					start_order--;
>> +					size >>=3D 1;
>> +
>> +					list_add(&freepage[size].lru,
>> +						&cc->freepages[start_order].pages);
>> +					cc->freepages[start_order].nr_pages++;
>> +					set_page_private(&freepage[size], start_order);
>> +				}
>> +				dst =3D (struct folio *)freepage;
>> +				goto done;
>> +			}
>> +		}
>> +		if (!has_isolated_pages) {
>> +			isolate_freepages(cc);
>> +			has_isolated_pages =3D true;
>> +			goto again;
>> +		}
>> +
>>  		if (!cc->freepages[order].nr_pages)
>>  			return NULL;
>>  	}
>> @@ -1842,6 +1876,7 @@ static struct folio *compaction_alloc(struct fol=
io *src, unsigned long data)
>>  	dst =3D list_first_entry(&cc->freepages[order].pages, struct folio, =
lru);
>>  	cc->freepages[order].nr_pages--;
>>  	list_del(&dst->lru);
>> +done:
>>  	post_alloc_hook(&dst->page, order, __GFP_MOVABLE);
>>  	if (order)
>>  		prep_compound_page(&dst->page, order);


--
Best Regards,
Yan, Zi

--=_MailMate_BD14FE1B-E5CC-48E5-91A1-105DB631D11D_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

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

iQJDBAEBCgAtFiEE6rR4j8RuQ2XmaZol4n+egRQHKFQFAmXGg5EPHHppeUBudmlk
aWEuY29tAAoJEOJ/noEUByhUavQP/RqgKMfm+7xK0zxvY+z6MYpwAT3ub4jOjWb2
ttzl25IopNd83ZobvW2SmJkdV/DB5BFL3kCv45Zn+go/fuk8uR7AldA4kE/S1s/W
QXDnNpmqvH8bN1+kHnEX4erwCvWqN7AXF0DqppLX3JI+bd3l65+MoW6gq0aWvz81
X32xr4yl826Ox5/3H0wT/u4xlccwSz1emXVcZYjdHit6CvC+1XthWFY/8kJVFQnF
05/Rz58qbBE4iBU9DjuYZQ9B2DU4U9DEwfvYETIaaVDv5OaQOGxF+QAG3UZO2eLc
gFUXQ8/Q18xCooo7fQUAXc6uIaVQkEsZWNsJ4eVzMVqgZzTK5gEEcIEd30NUNjBW
6aj7v+5gS3a3QeCfY+NqhwNXMulMua9nJDgGvppsmCK+ZQojZAY2nValPUXU4wtt
1p4Bw9G2ATay2LOV3CyfhQT29rMIZYZjjZMC3gnrv78jKNgWTg23otnTHJNVUGU2
CkGBbT2h7bmMhCZH53jaEItghtXNZsZ0Cv/eMmSN/UHzGUxSLtIfaAakTaP6rvPr
ibjskAjGPgPCcO/2Al/oRGJvsFM1OTsBAfsshLDp5+tW0sYUsb/FZVPz1864y148
qSYHAt8v70JrJKIorpQj7NWT/9zv3XJ4m+mo+/s3s89YbXT+i/ATsi/X+vo4Clwn
XtHTPElZ
=/ciZ
-----END PGP SIGNATURE-----

--=_MailMate_BD14FE1B-E5CC-48E5-91A1-105DB631D11D_=--