All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Michal Hocko <mhocko@kernel.org>, David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	osalvador@suse.de, richard.weiyang@gmail.com, rppt@linux.ibm.com
Subject: Re: [PATCH] mm, memory_hotplug: Fix the wrong usage of N_HIGH_MEMORY
Date: Wed, 20 Mar 2019 17:29:11 +0800	[thread overview]
Message-ID: <20190320092911.GO18740@MiWiFi-R3L-srv> (raw)
In-Reply-To: <e5bc1884-ad75-63e3-ede5-e7ce88ec0f01@redhat.com>

On 03/20/19 at 10:11am, David Hildenbrand wrote:
> On 20.03.19 10:06, Baoquan He wrote:
> > On 03/20/19 at 09:46am, Michal Hocko wrote:
> >> On Wed 20-03-19 16:07:32, Baoquan He wrote:
> >>> In function node_states_check_changes_online(), N_HIGH_MEMORY is used
> >>> to substitute ZONE_HIGHMEM directly. This is not right. N_HIGH_MEMORY
> >>> always has value '3' if CONFIG_HIGHMEM=y, while ZONE_HIGHMEM's value
> >>> is not. It depends on whether CONFIG_ZONE_DMA/CONFIG_ZONE_DMA32 are
> >>> enabled. Obviously it's not true for CONFIG_ZONE_DMA32 on 32bit system,
> >>> and CONFIG_ZONE_DMA is also optional.
> >>>
> >>> Replace it with ZONE_HIGHMEM.
> >>
> >> N*MEMORY is confusing as hell but I am really curious whether we have
> >> ZONE_DMA32 and ZONE_HIGMEM together?
> > 
> > Not sure. AFAIK, on x86_32 it can't be.
> > 
> >>
> >> That being said N.*MEMORY is intended to check for nodes rather than
> >> zones so the patch looks good to me but I think the above explanation is
> >> misleading and will add even more mud to the picture when somebody tries
> >> to understand what the heck is going on here.
> > 
> > Yes, agree. I also thought this again after I sent out patch, feel log is not
> > good. As you said, they are value of enum node_states and enum zone_type
> > separately.
> > 
> > How about this:
> > 
> > ~~~
> > In function node_states_check_changes_online(), N_HIGH_MEMORY is used
> > to substitute ZONE_HIGHMEM directly. This is not right. N_HIGH_MEMORY
> > is to mark the memory state of node. Here zone index is checked, which
> > should be compared with 'ZONE_HIGHMEM' accordingly.
> > 
> > Replace it with ZONE_HIGHMEM.
> 
> Reviewed-by: David Hildenbrand <david@redhat.com>

Thanks, both. Will use this log and repost.

Thanks
Baoquan

  reply	other threads:[~2019-03-20  9:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  8:07 [PATCH] mm, memory_hotplug: Fix the wrong usage of N_HIGH_MEMORY Baoquan He
2019-03-20  8:46 ` Michal Hocko
2019-03-20  9:06   ` Baoquan He
2019-03-20  9:11     ` David Hildenbrand
2019-03-20  9:29       ` Baoquan He [this message]
2019-03-20  9:37     ` Michal Hocko
2019-03-20 12:27 ` Oscar Salvador
2019-03-20 12:28 ` Oscar Salvador
2019-03-20 19:12 ` Andrew Morton
2019-03-20 19:53   ` Michal Hocko

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=20190320092911.GO18740@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@linux.ibm.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.