linux-kernel - Re: 回复: Re: [PATCH] migrate_pages: modify max number of pages to migrate in batch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87zfr9y6y7.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Tue, 25 Jun 2024 12:36:32 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: 李真能 <lizhenneng@...inos.cn>
Cc: Andrew Morton <akpm@...ux-foundation.org>,  linux-mm
 <linux-mm@...ck.org>,  linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: 回复: Re: [PATCH] migrate_pages: modify max
 number of pages to
 migrate in batch

李真能 <lizhenneng@...inos.cn> writes:

> ----
>
>  
>
>  
>
> 主　题：Re: [PATCH] migrate_pages: modify max number of pages to migrate in batch 
> 日　期：2024-06-25 09:17 
> 发件人：ying.huang 
> 收件人：李真能;
>
> Hi, Zhenneng,
>
> Zhenneng Li writes:
>
>> We restrict the number of pages to be migrated to no more than
>> HPAGE_PMD_NR or NR_MAX_BATCHED_MIGRATION, but in fact, the
>> number of pages to be migrated may reach 2*HPAGE_PMD_NR-1 or 2
>> *NR_MAX_BATCHED_MIGRATION-1, it's not in inconsistent with the context.
>
> Yes. It's not HPAGE_PMD_NR exactly.
>
>> Please refer to the patch: 42012e0436d4(migrate_pages: restrict number
>> of pages to migrate in batch)
>>
>> Signed-off-by: Zhenneng Li 
>> ---
>> mm/migrate.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index 781979567f64..7a4b37aac9e8 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -1961,7 +1961,7 @@ int migrate_pages(struct list_head *from, new_folio_t get_new_folio,
>> break;
>> }
>> if (nr_pages >= NR_MAX_BATCHED_MIGRATION)
>> - list_cut_before(&folios, from, &folio2->lru);
>> + list_cut_before(&folios, from, &folio->lru);
>
> If the first entry of the list "from" is a THP with size HPAGE_PMD_NR,
> "folio" will be the first entry of from, so that "folios" will be empty.
> Right?
>  
> Yes, It's right, so we can check whether it is the first entry of the list "from", new patch are as follows(attachment is
> patch file):
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 781979567f64..cce8e2b85e89 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1957,11 +1957,12 @@ int migrate_pages(struct list_head *from, new_folio_t get_new_folio,
> }
>
> nr_pages += folio_nr_pages(folio);
> - if (nr_pages >= NR_MAX_BATCHED_MIGRATION)
> + if ((nr_pages >= NR_MAX_BATCHED_MIGRATION) &&
> + (!list_first_entry(from, struct folio, lru)))
> break;
> }
> if (nr_pages >= NR_MAX_BATCHED_MIGRATION)
> - list_cut_before(&folios, from, &folio2->lru);
> + list_cut_before(&folios, from, &folio->lru);
> else
> list_splice_init(from, &folios);
> if (mode == MIGRATE_ASYNC)
>

I don't think that it's necessary to change this.  Yes, the max batch
number of the page migration may be 2*HPAGE_PMD_NR-1.  Does it cause any
latency issue for you?

>
>> else
>> list_splice_init(from, &folios);
>> if (mode == MIGRATE_ASYNC)

--
Best Regards,
Huang, Ying