All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Tianyou" <tianyou.li@intel.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>,
	Wei Yang <richard.weiyang@gmail.com>
Cc: <linux-mm@kvack.org>, Yong Hu <yong.hu@intel.com>,
	Nanhai Zou <nanhai.zou@intel.com>, Yuan Liu <yuan1.liu@intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
	Yu C Chen <yu.c.chen@intel.com>, Pan Deng <pan.deng@intel.com>,
	Chen Zhang <zhangchen.kidd@jd.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] mm/memory hotplug/unplug: Optimize zone->contiguous update when changes pfn range
Date: Mon, 8 Dec 2025 23:05:49 +0800	[thread overview]
Message-ID: <49bda900-e79f-4d43-8ea8-46e7d9f78c2d@intel.com> (raw)
In-Reply-To: <7761ab95-4cf4-4a6f-a979-ce862ad97f85@intel.com>

Sorry for the delayed. We were working on a suspected issue and now the 
patch v5 is out. Thanks for your review in advance.


Regards,

Tianyou


On 12/2/2025 6:41 PM, Li, Tianyou wrote:
>
> On 12/2/2025 6:24 PM, David Hildenbrand (Red Hat) wrote:
>>>>> +};
>>>>
>>>> I don't like that the defines don't match the enum name (zone_c... vs.
>>>> CONT... ).
>>>>
>>>> Essentially you want a "yes / no / maybe" tristate. I don't think we
>>>> have an existing type for that, unfortunately.
>>>>
>>>> enum zone_contig_state {
>>>>      ZONE_CONTIG_YES,
>>>>      ZONE_CONTIG_NO,
>>>>      ZONE_CONTIG_MAYBE,
>>>> };
>>>>
>>>> Maybe someone reading along has a better idea.
>>>>
>>>
>>> I agree it's better. Will wait for a day or two to make the change.
>>>
>>
>> Yes, good idea. No needs to rush at this point because the merge 
>> window just opened up.
>>
>
> Got it. Allow me to take one more day then complete the patch v5 with 
> sufficient testing.
>
>
>>>
>>>>> +
>>>>> +void set_zone_contiguous(struct zone *zone, enum
>>>>> zone_contiguous_state state);
>>>>>    bool pfn_range_intersects_zones(int nid, unsigned long start_pfn,
>>>>>                   unsigned long nr_pages);
>>>>>    diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>>>> index 0be83039c3b5..b74e558ce822 100644
>>>>> --- a/mm/memory_hotplug.c
>>>>> +++ b/mm/memory_hotplug.c
>>>>> @@ -544,6 +544,32 @@ static void update_pgdat_span(struct pglist_data
>>>>> *pgdat)
>>>>>        pgdat->node_spanned_pages = node_end_pfn - node_start_pfn;
>>>>>    }
>>>>>    +static enum zone_contiguous_state __meminit
>>>>> clear_zone_contiguous_for_shrinking(
>>>>> +        struct zone *zone, unsigned long start_pfn, unsigned long
>>>>> nr_pages)
>>>>> +{
>>>>> +    const unsigned long end_pfn = start_pfn + nr_pages;
>>>>> +    enum zone_contiguous_state result = CONTIGUOUS_UNDETERMINED;
>>>>> +
>>>>> +    /*
>>>>> +     * If the removed pfn range inside the original zone span, the
>>>>> contiguous
>>>>> +     * property is surely false.
>>>>> +     */
>>>>> +    if (start_pfn > zone->zone_start_pfn && end_pfn <
>>>>> zone_end_pfn(zone))
>>>>> +        result = CONTIGUOUS_DEFINITELY_NOT;
>>>>> +
>>>>> +    /*
>>>>> +     * If the removed pfn range is at the beginning or end of the
>>>>> +     * original zone span, the contiguous property is preserved when
>>>>> +     * the original zone is contiguous.
>>>>> +     */
>>>>> +    else if (start_pfn == zone->zone_start_pfn || end_pfn ==
>>>>> zone_end_pfn(zone))
>>>>> +        result = zone->contiguous ?
>>>>> +            CONTIGUOUS_DEFINITELY : CONTIGUOUS_UNDETERMINED;
>>>>> +
>>>>
>>>> See my comment below on how to make this readable.
>>>>
>>>>> +    clear_zone_contiguous(zone);
>>>>> +    return result;
>>>>> +}
>>>>> +
>>>>>    void remove_pfn_range_from_zone(struct zone *zone,
>>>>>                          unsigned long start_pfn,
>>>>>                          unsigned long nr_pages)
>>>>> @@ -551,6 +577,7 @@ void remove_pfn_range_from_zone(struct zone 
>>>>> *zone,
>>>>>        const unsigned long end_pfn = start_pfn + nr_pages;
>>>>>        struct pglist_data *pgdat = zone->zone_pgdat;
>>>>>        unsigned long pfn, cur_nr_pages;
>>>>> +    enum zone_contiguous_state contiguous_state =
>>>>> CONTIGUOUS_UNDETERMINED;
>>>>>          /* Poison struct pages because they are now uninitialized
>>>>> again. */
>>>>>        for (pfn = start_pfn; pfn < end_pfn; pfn += cur_nr_pages) {
>>>>> @@ -571,12 +598,13 @@ void remove_pfn_range_from_zone(struct zone 
>>>>> *zone,
>>>>>        if (zone_is_zone_device(zone))
>>>>>            return;
>>>>>    -    clear_zone_contiguous(zone);
>>>>> +    contiguous_state = clear_zone_contiguous_for_shrinking(
>>>>> +                zone, start_pfn, nr_pages);
>>>>
>>>> Reading this again, I wonder whether it would be nicer to have
>>>> something like:
>>>>
>>>> new_contig_state = zone_contig_state_after_shrinking();
>>>> clear_zone_contiguous(zone);
>>>>
>>>> or sth like that. Similar for the growing case.
>>>>
>>>
>>> In both shrinking and growing case, separate the clear_zone_contiguous
>>> from the logic of zone state check, right?
>>
>> Yes, I think that makes it look a bit nicer.
>>
>
> Thanks for the confirmation David. Noted and will do. Thanks.
>
>
>
>


  reply	other threads:[~2025-12-08 15:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01 13:22 [PATCH v4] mm/memory hotplug/unplug: Optimize zone->contiguous update when changes pfn range Tianyou Li
2025-12-01 18:54 ` David Hildenbrand (Red Hat)
2025-12-01 23:40   ` Li, Tianyou
2025-12-02 10:24     ` David Hildenbrand (Red Hat)
2025-12-02 10:41       ` Li, Tianyou
2025-12-08 15:05         ` Li, Tianyou [this message]
2025-12-02 10:57   ` Mike Rapoport
2025-12-03  9:35     ` Li, Tianyou

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=49bda900-e79f-4d43-8ea8-46e7d9f78c2d@intel.com \
    --to=tianyou.li@intel.com \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nanhai.zou@intel.com \
    --cc=osalvador@suse.de \
    --cc=pan.deng@intel.com \
    --cc=qiuxu.zhuo@intel.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=yong.hu@intel.com \
    --cc=yu.c.chen@intel.com \
    --cc=yuan1.liu@intel.com \
    --cc=zhangchen.kidd@jd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.