On 8 Aug 2025, at 11:24, Zi Yan wrote:
> On 7 Aug 2025, at 23:15, Wei Yang wrote:
>
>> On Thu, Aug 07, 2025 at 01:05:09PM -0400, Zi Yan wrote:
>>> On 7 Aug 2025, at 4:55, Wei Yang wrote:
>>>
>>>> On Tue, Aug 05, 2025 at 10:20:43PM -0400, Zi Yan wrote:
>>>> [...]
>>>>>
>>>>> - if (in_folio_offset < 0 ||
>>>>> - in_folio_offset >= folio_nr_pages(folio)) {
>>>>> + if (in_folio_offset < 0 || in_folio_offset >= nr_pages) {
>>>>> if (!split_folio_to_order(folio, target_order))
>>>>> split++;
>>>>> } else {
>>>>> - struct page *split_at = folio_page(folio,
>>>>> - in_folio_offset);
>>>>> - if (!folio_split(folio, target_order, split_at, NULL))
>>>>> + struct page *split_at =
>>>>> + folio_page(folio, in_folio_offset);
>>>>> + if (!folio_split(folio, target_order, split_at, NULL)) {
>>>>> split++;
>>>>> + addr += PAGE_SIZE * nr_pages;
>>>>> + }
>>>>
>>>> Are we sure addr points to the folio start?
>>>
>>> David pointed it out. Will use addr += PAGE_SIZE * (nr_pages - 1).
>>>
>>
>> No, let me be more clear. I am talking about the addr in next iteration. I am
>> talking about the addr in this round.
>>
>> For an addr in the middle of 2M, we still could get the large folio if my
>> understanding is correct. Then (addr + whole folio size) seems wrong.
>>
>> addr
>> |
>> v
>> +-------------------+
>> | |
>> +-------------------+
>>
>> Not sure this would be the case.
>
> Got it. addr should be aligned up to PAGE_SIZE * nr_pages to get to the next
> folio. Thanks.
On a second thought, this new stepping would mess up with PTE-mapped folio
split.
I will drop this patch (pr_debug part will be moved to Patch 1) and change
split_huge_page_test.c instead.
--
Best Regards,
Yan, Zi
