From: Joonsoo Kim <js1304@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Jerome Glisse <jglisse@redhat.com>,
Reza Arbab <arbab@linux.vnet.ibm.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Andi Kleen <ak@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: your mail
Date: Thu, 27 Apr 2017 11:08:38 +0900 [thread overview]
Message-ID: <20170427020835.GA29169@js1304-desktop> (raw)
In-Reply-To: <20170426091906.GB12504@dhcp22.suse.cz>
On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > [...]
> > >
> > > > > You are trying to change a semantic of something that has a well defined
> > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > you are proposing is conflating two different things together.
> > > >
> > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > It would be original semantic of pfn_valid().
> > > >
> > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > zone information,"
> > >
> > > I do not see any guarantee about the zone information anywhere. In fact
> > > this is not true with the original implementation as I've tried to
> > > explain already. We do have new pages associated with a zone but that
> > > association might change during the online phase. So you cannot really
> > > rely on that information until the page is online. There is no real
> > > change in that regards after my rework.
> >
> > I know that what you did doesn't change thing much. What I try to say
> > is that previous implementation related to pfn_valid() in hotplug is
> > wrong. Please do not assume that hotplug implementation is correct and
> > other pfn_valid() users are incorrect. There is no design document so
> > I'm not sure which one is correct but assumption that pfn_valid() user
> > can access whole the struct page information makes much sense to me.
>
> Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> still need pfn_valid to work for those pfns. Really, pfn_valid has a
It's really contrary example to your insist. They requires not only
struct page but also other information, especially, the zone index.
They checks zone idx to know whether this page is for ZONE_DEVICE or not.
So, pfn_valid() for ZONE_DEVICE pages assume that struct page has all
the valid information. It's perfectly matched with my suggestion.
Online isn't important issue here. What the important point is the condition
that pfn_valid() return true. pfn_valid() for ZONE_DEVICE returns true after
arch_add_memory() since all the struct page information is fixed there.
If zone of hotplugged memory cannot be fixed at this moment, you can
defef it until all the information is fixed (onlining). That
seems to be better semantic of pfn_valid() to me.
> different meaning than you would like it to have. Who knows how many
> others like that are lurking there. I feel much more comfortable to go
> and hunt already broken code and fix it rathert than break something
> unexpectedly.
I think that I did my best to explain my reasoning. It seems that we
cannot agree with each other so it's better for some others to express
their opinion to this problem. I will stop this discussion from now
on.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-04-27 2:08 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
2017-04-10 11:03 ` [PATCH 1/9] mm: remove return value from init_currently_empty_zone Michal Hocko
2017-04-11 8:10 ` Balbir Singh
2017-04-13 12:03 ` Vlastimil Babka
2017-04-13 19:43 ` YASUAKI ISHIMATSU
2017-04-10 11:03 ` [PATCH 2/9] mm, memory_hotplug: use node instead of zone in can_online_high_movable Michal Hocko
2017-04-13 12:46 ` Vlastimil Babka
2017-04-13 19:45 ` YASUAKI ISHIMATSU
2017-04-10 11:03 ` [PATCH 3/9] mm: drop page_initialized check from get_nid_for_pfn Michal Hocko
2017-04-13 12:59 ` Vlastimil Babka
2017-04-10 11:03 ` [PATCH 4/9] mm, memory_hotplug: get rid of is_zone_device_section Michal Hocko
2017-04-10 16:20 ` Jerome Glisse
2017-04-10 16:31 ` Michal Hocko
2017-04-13 13:05 ` Vlastimil Babka
2017-04-17 20:12 ` Jerome Glisse
2017-04-18 7:19 ` Michal Hocko
2017-04-10 11:03 ` [PATCH 5/9] mm, memory_hotplug: split up register_one_node Michal Hocko
2017-04-13 14:05 ` Vlastimil Babka
2017-04-13 14:13 ` Michal Hocko
2017-04-10 11:03 ` [PATCH 6/9] mm, memory_hotplug: do not associate hotadded memory to zones until online Michal Hocko
2017-04-10 16:25 ` [PATCH v3 " Michal Hocko
2017-04-20 8:25 ` Vlastimil Babka
2017-04-20 9:06 ` Michal Hocko
2017-04-20 10:51 ` Vlastimil Babka
2017-04-10 11:03 ` [PATCH 7/9] mm, memory_hotplug: replace for_device by want_memblock in arch_add_memory Michal Hocko
2017-04-20 8:29 ` Vlastimil Babka
2017-04-10 11:03 ` [PATCH 8/9] mm, memory_hotplug: fix the section mismatch warning Michal Hocko
2017-04-10 11:03 ` [PATCH 9/9] mm, memory_hotplug: remove unused cruft after memory hotplug rework Michal Hocko
2017-04-20 8:38 ` Vlastimil Babka
2017-04-10 14:27 ` [PATCH -v2 0/9] mm: make movable onlining suck less Igor Mammedov
2017-04-10 14:56 ` Michal Hocko
2017-04-10 15:22 ` Michal Hocko
2017-04-10 15:31 ` Michal Hocko
2017-04-11 8:01 ` Igor Mammedov
2017-04-11 8:41 ` Michal Hocko
2017-04-11 9:53 ` Igor Mammedov
2017-04-11 10:47 ` Michal Hocko
2017-04-10 16:02 ` Michal Hocko
2017-04-18 8:23 ` Vlastimil Babka
2017-04-10 16:09 ` Michal Hocko
2017-04-11 6:38 ` Igor Mammedov
2017-04-11 9:23 ` Michal Hocko
2017-04-11 9:59 ` Igor Mammedov
2017-04-11 11:01 ` Michal Hocko
2017-04-11 11:38 ` Michal Hocko
2017-04-11 12:38 ` Michal Hocko
2017-04-10 15:43 ` Reza Arbab
2017-04-11 8:59 ` Michal Hocko
2017-04-10 16:35 ` Jerome Glisse
2017-04-10 17:53 ` Michal Hocko
2017-04-11 2:51 ` Balbir Singh
2017-04-11 17:03 ` Michal Hocko
2017-04-17 21:51 ` Dan Williams
2017-04-18 7:14 ` Michal Hocko
2017-04-18 16:42 ` Dan Williams
2017-04-18 19:54 ` Michal Hocko
2017-04-20 3:37 ` Dan Williams
2017-04-15 12:17 ` Michal Hocko
2017-04-15 12:17 ` [PATCH 1/3] mm: consider zone which is not fully populated to have holes Michal Hocko
2017-04-18 8:45 ` Vlastimil Babka
2017-04-18 9:27 ` Michal Hocko
2017-04-19 11:59 ` Vlastimil Babka
2017-04-19 12:16 ` Michal Hocko
2017-04-19 12:34 ` Vlastimil Babka
2017-04-19 12:50 ` Michal Hocko
2017-04-15 12:17 ` [PATCH 2/3] mm, compaction: skip over holes in __reset_isolation_suitable Michal Hocko
2017-04-15 12:17 ` [PATCH 3/3] mm: __first_valid_page skip over offline pages Michal Hocko
2017-04-17 5:47 ` your mail Joonsoo Kim
2017-04-17 8:15 ` Michal Hocko
2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 12:13 ` Michal Hocko
2017-04-21 2:46 ` [lkp-robot] 73821bb516: WARNING:at_mm/memblock.c:#memblock_virt_alloc_internal kernel test robot
2017-04-21 8:05 ` Michal Hocko
2017-04-21 4:38 ` your mail Joonsoo Kim
2017-04-21 7:16 ` Michal Hocko
2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 7:53 ` Michal Hocko
2017-04-25 2:50 ` Joonsoo Kim
2017-04-26 9:19 ` Michal Hocko
2017-04-27 2:08 ` Joonsoo Kim [this message]
2017-04-27 15:10 ` Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26 0:12 ` Jeff Xu
2025-02-26 5:42 ` your mail Lorenzo Stoakes
2025-02-28 0:55 ` Jeff Xu
2025-02-28 9:35 ` Lorenzo Stoakes
2025-02-28 17:24 ` Jeff Xu
2025-02-28 17:30 ` Lorenzo Stoakes
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
2019-02-26 23:49 ` Roman Gushchin
2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` your mail Christoph Lameter
2010-06-16 16:33 Jan Kara
2010-06-16 22:15 ` your mail Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
2010-06-22 13:54 ` Jan Kara
2010-06-22 14:12 ` Wu Fengguang
[not found] <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
2007-02-05 12:36 ` Joerg Roedel
2003-01-24 5:54 Anoop J.
2003-01-24 6:28 ` David Lang
2003-01-24 8:51 ` Anoop J.
2003-01-24 8:48 ` David Lang
2003-01-24 9:49 ` Anoop J.
2003-01-24 19:14 ` David Lang
2003-01-24 19:40 ` Maciej W. Rozycki
2003-01-24 5:08 (unknown), Anoop J.
2003-01-24 5:11 ` your mail David Lang
2003-01-24 6:06 ` John Alvord
2003-01-25 2:29 ` Jason Papadopoulos
2003-01-25 2:26 ` Larry McVoy
2003-01-25 17:47 ` Eric W. Biederman
2003-01-25 23:10 ` Larry McVoy
2003-01-26 8:12 ` David S. Miller
2002-04-21 14:54 raciel
2002-04-21 19:12 ` your mail William Lee Irwin III
2002-01-02 14:20 mehul radheshyam choube
2002-01-03 16:40 ` your mail Rik van Riel
2001-08-04 11:10 Mahmoud Taghizadeh
2001-08-04 13:18 ` your mail Francois Romieu
2001-06-08 1:36 jnn
2001-06-08 13:16 ` your mail Ralf Baechle
2000-09-04 12:01 Sahil
2000-09-04 15:35 ` your mail Rik van Riel
2000-03-28 8:19 pnilesh
2000-03-28 13:26 ` Stephen C. Tweedie
1998-02-25 22:15 Rik van Riel
1998-02-25 22:48 ` your mail Linus Torvalds
1998-02-25 23:26 ` Rik van Riel
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=20170427020835.GA29169@js1304-desktop \
--to=js1304@gmail.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arbab@linux.vnet.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=imammedo@redhat.com \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=qiuxishi@huawei.com \
--cc=rientjes@google.com \
--cc=slaoub@gmail.com \
--cc=toshi.kani@hpe.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=yasu.isimatu@gmail.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;
as well as URLs for NNTP newsgroup(s).