From: Wei Yang <richardw.yang@linux.intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: Baoquan He <bhe@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, richardw.yang@linux.intel.com,
mhocko@suse.com, osalvador@suse.de
Subject: Re: [PATCH] mm/hotplug: Adjust shrink_zone_span() to keep the old logic
Date: Fri, 7 Feb 2020 07:44:40 +0800 [thread overview]
Message-ID: <20200206234440.GA14560@richard> (raw)
In-Reply-To: <7ecaf36f-9f70-05bd-05fc-6dec82b7d559@redhat.com>
On Thu, Feb 06, 2020 at 09:50:07AM +0100, David Hildenbrand wrote:
>On 06.02.20 06:39, Baoquan He wrote:
>> In commit 950b68d9178b ("mm/memory_hotplug: don't check for "all holes"
>> in shrink_zone_span()"), the zone->zone_start_pfn/->spanned_pages
>> resetting is moved into the if()/else if() branches, if the zone becomes
>> empty. However the 2nd resetting code block may cause misunderstanding.
>>
>> So take the resetting codes out of the conditional checking and handling
>> branches just as the old code does, the find_smallest_section_pfn()and
>> find_biggest_section_pfn() searching have done the the same thing as
>> the old for loop did, the logic is kept the same as the old code. This
>> can remove the possible confusion.
>>
>> Signed-off-by: Baoquan He <bhe@redhat.com>
>> ---
>> mm/memory_hotplug.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 089b6c826a9e..475d0d68a32c 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -398,7 +398,7 @@ static unsigned long find_biggest_section_pfn(int nid, struct zone *zone,
>> static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>> unsigned long end_pfn)
>> {
>> - unsigned long pfn;
>> + unsigned long pfn = zone->zone_start_pfn;
>> int nid = zone_to_nid(zone);
>>
>> zone_span_writelock(zone);
>> @@ -414,9 +414,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>> if (pfn) {
>> zone->spanned_pages = zone_end_pfn(zone) - pfn;
>> zone->zone_start_pfn = pfn;
>> - } else {
>> - zone->zone_start_pfn = 0;
>> - zone->spanned_pages = 0;
>> }
>> } else if (zone_end_pfn(zone) == end_pfn) {
>> /*
>> @@ -429,10 +426,11 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>> start_pfn);
>> if (pfn)
>> zone->spanned_pages = pfn - zone->zone_start_pfn + 1;
>> - else {
>> - zone->zone_start_pfn = 0;
>> - zone->spanned_pages = 0;
>> - }
>> + }
>> +
>> + if (!pfn) {
>> + zone->zone_start_pfn = 0;
>> + zone->spanned_pages = 0;
>> }
>> zone_span_writeunlock(zone);
>> }
>>
>
>So, what if your zone starts at pfn 0? Unlikely that we can actually
>offline that, but still it is more confusing than the old code IMHO.
>Then I prefer to drop the second else case as discussed instead.
>
Sorry, I just catch up with this thread.
If zone starts at 0, find_smallest_section_pfn() will be called only when we
want to remove the first section [0, secion_size].
Then find_smallest_section_pfn() return value has two possibilities:
* a non-0 section pfn if it still has
* 0 if the zone is empty
This looks good to me.
Or I may misunderstand your point, would you mind sharing more light on your
finding?
Thanks :-)
>--
>Thanks,
>
>David / dhildenb
--
Wei Yang
Help you, Help me
prev parent reply other threads:[~2020-02-06 23:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 5:39 [PATCH] mm/hotplug: Adjust shrink_zone_span() to keep the old logic Baoquan He
2020-02-06 6:16 ` Wei Yang
2020-02-06 8:50 ` David Hildenbrand
2020-02-06 9:35 ` Baoquan He
2020-02-06 9:48 ` David Hildenbrand
2020-02-06 10:00 ` Baoquan He
2020-02-06 10:02 ` David Hildenbrand
2020-02-06 10:05 ` David Hildenbrand
2020-02-06 10:12 ` Baoquan He
2020-02-06 23:44 ` Wei Yang [this message]
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=20200206234440.GA14560@richard \
--to=richardw.yang@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
/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.