linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	David Hildenbrand <david@redhat.com>,
	Yang Shi <yang@os.amperecomputing.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Yu Zhao <yuzhao@google.com>, John Hubbard <jhubbard@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kairui Song <kasong@tencent.com>
Subject: Re: [PATCH v10 2/8] mm/huge_memory: add two new (not yet used) functions for folio_split()
Date: Mon, 10 Mar 2025 13:05:12 -0400	[thread overview]
Message-ID: <534ACFEE-3FD9-47B2-B3A9-45F898BC9CCF@nvidia.com> (raw)
In-Reply-To: <Z88ar5YS99HsIRYo@casper.infradead.org>

On 10 Mar 2025, at 13:00, Matthew Wilcox wrote:

> On Mon, Mar 10, 2025 at 12:42:06PM -0400, Zi Yan wrote:
>>> Because of the “Careful” comment. But new_folio->* should be fine,
>>> since it is the same as new_head. So I probably can replace all
>>> new_head with new_folio except those VM_BUG_ON_PAGE checks?
>
> Why not also the VM_BUG_ON_PAGE check?  I mean:
>
>> @@ -3364,8 +3364,8 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>  		/* ->mapping in first and second tail page is replaced by other uses */
>>  		VM_BUG_ON_PAGE(new_nr_pages > 2 && new_head->mapping != TAIL_MAPPING,
>>  			       new_head);
>
> 		VM_BUG_ON_PAGE(new_nr_pages > 2 && new_folio->mapping != TAIL_MAPPING, new_head);

We are checking new_folio but dump new_head, so it can cause some confusion.
But it might not be that bad.
>
> (or we could just ditch the assert entirely; it's not all that useful)

I am open to that.

>
>> -		new_head->mapping = head->mapping;
>> -		new_head->index = head->index + index;
>> +		new_folio->mapping = head->mapping;
>> +		new_folio->index = head->index + index;
>
> 	new_folio->mapping = folio->mapping
> 	new_folio->index = folio->index +index;
>
> (um, and that index + index looks weird; better name might be just 'i')

OK. Let me make the changes you suggested and fold it to Hugh’s fix patch,
before Andrew picks that up.

Best Regards,
Yan, Zi


  reply	other threads:[~2025-03-10 17:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 17:39 [PATCH v10 0/8] Buddy allocator like (or non-uniform) folio split Zi Yan
2025-03-07 17:39 ` [PATCH v10 1/8] xarray: add xas_try_split() to split a multi-index entry Zi Yan
2025-03-07 17:39 ` [PATCH v10 2/8] mm/huge_memory: add two new (not yet used) functions for folio_split() Zi Yan
2025-03-10 16:14   ` Zi Yan
2025-03-10 17:32     ` Zi Yan
2025-03-13 14:08       ` Zi Yan
2025-03-10 16:30   ` Matthew Wilcox
2025-03-10 16:39     ` Zi Yan
2025-03-10 16:42       ` Zi Yan
2025-03-10 17:00         ` Matthew Wilcox
2025-03-10 17:05           ` Zi Yan [this message]
2025-03-07 17:39 ` [PATCH v10 3/8] mm/huge_memory: move folio split common code to __folio_split() Zi Yan
2025-03-07 17:39 ` [PATCH v10 4/8] mm/huge_memory: add buddy allocator like (non-uniform) folio_split() Zi Yan
2025-03-07 17:39 ` [PATCH v10 5/8] mm/huge_memory: remove the old, unused __split_huge_page() Zi Yan
2025-03-07 17:39 ` [PATCH v10 6/8] mm/huge_memory: add folio_split() to debugfs testing interface Zi Yan
2025-03-07 17:40 ` [PATCH v10 7/8] mm/truncate: use folio_split() in truncate operation Zi Yan
2025-03-07 17:40 ` [PATCH v10 8/8] selftests/mm: add tests for folio_split(), buddy allocator like split 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=534ACFEE-3FD9-47B2-B3A9-45F898BC9CCF@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=kasong@tencent.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=yang@os.amperecomputing.com \
    --cc=yuzhao@google.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