linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	Yang Shi <shy828301@gmail.com>, Huang Ying <ying.huang@intel.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	"Yin, Fengwei" <fengwei.yin@intel.com>,
	SeongJae Park <sj@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] mm/migrate: split source folio if it is on deferred split list
Date: Tue, 26 Mar 2024 09:26:48 -0400	[thread overview]
Message-ID: <8DAC0D9E-9B0D-4035-9211-2190C6F8284A@nvidia.com> (raw)
In-Reply-To: <1ecde325-097b-49e9-9f1f-d93edbc8e1f1@linux.alibaba.com>

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

On 26 Mar 2024, at 2:19, Baolin Wang wrote:

> On 2024/3/23 03:33, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> If the source folio is on deferred split list, it is likely some subpages
>> are not used. Split it before migration to avoid migrating unused subpages.
>>
>> Commit 616b8371539a6 ("mm: thp: enable thp migration in generic path")
>> did not check if a THP is on deferred split list before migration, thus,
>> the destination THP is never put on deferred split list even if the source
>> THP might be. The opportunity of reclaiming free pages in a partially
>> mapped THP during deferred list scanning is lost, but no other harmful
>> consequence is present[1].
>>
>>  From v4:
>> 1. Simplify _deferred_list check without locking and do not count as
>>     migration failures. (per Matthew Wilcox)
>>
>>  From v3:
>> 1. Guarded deferred list code behind CONFIG_TRANSPARENT_HUGEPAGE to avoid
>>     compilation error (per SeongJae Park).
>>
>>  From v2:
>> 1. Split the source folio instead of migrating it (per Matthew Wilcox)[2].
>>
>>  From v1:
>> 1. Used dst to get correct deferred split list after migration
>>     (per Ryan Roberts).
>>
>> [1]: https://lore.kernel.org/linux-mm/03CE3A00-917C-48CC-8E1C-6A98713C817C@nvidia.com/
>> [2]: https://lore.kernel.org/linux-mm/Ze_P6xagdTbcu1Kz@casper.infradead.org/
>>
>> Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>>   mm/migrate.c | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index ab9856f5931b..6bd9319624a3 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -1652,6 +1652,29 @@ static int migrate_pages_batch(struct list_head *from,
>>    			cond_resched();
>>  +			/*
>> +			 * The rare folio on the deferred split list should
>> +			 * be split now. It should not count as a failure.
>> +			 * Only check it without removing it from the list.
>> +			 * Since the folio can be on deferred_split_scan()
>> +			 * local list and removing it can cause the local list
>> +			 * corruption. Folio split process below can handle it
>> +			 * with the help of folio_ref_freeze().
>> +			 *
>> +			 * nr_pages > 2 is needed to avoid checking order-1
>> +			 * page cache folios. They exist, in contrast to
>> +			 * non-existent order-1 anonymous folios, and do not
>> +			 * use _deferred_list.
>> +			 */
>> +			if (nr_pages > 2 &&
>> +			   !list_empty(&folio->_deferred_list)) {
>> +				if (try_split_folio(folio, from) == 0) {
>
> IMO, we should move the split folios into the 'split_folios' list instead of the 'from' list, otherwise there might be unhandled folios remaining in the from list.

Can you elaborate on the actual situation you are thinking about? Thanks.

>
>> +					stats->nr_thp_split += is_thp;
>> +					stats->nr_split++;
>> +					continue;
>> +				}
>> +			}
>> +
>>   			/*
>>   			 * Large folio migration might be unsupported or
>>   			 * the allocation might be failed so we should retry
>>
>> base-commit: 08a487ab26d541a3bd0adaee144f684b724d233b


--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

  reply	other threads:[~2024-03-26 13:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 19:33 Zi Yan
2024-03-26  6:19 ` Baolin Wang
2024-03-26 13:26   ` Zi Yan [this message]
2024-03-26 14:42     ` Baolin Wang
2024-03-26 14:53       ` Zi Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8DAC0D9E-9B0D-4035-9211-2190C6F8284A@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=fengwei.yin@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=sj@kernel.org \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox