linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	David Rientjes <rientjes@google.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	linux-api@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, qiuxishi@huawei.com,
	toshi.kani@hpe.com, xieyisheng1@huawei.com, slaoub@gmail.com,
	iamjoonsoo.kim@lge.com, vbabka@suse.cz,
	Zhang Zhen <zhenzhang.zhang@huawei.com>,
	Reza Arbab <arbab@linux.vnet.ibm.com>,
	Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
	Tang Chen <tangchen@cn.fujitsu.com>
Subject: Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)
Date: Fri, 10 Mar 2017 16:53:33 +0100	[thread overview]
Message-ID: <20170310155333.GN3753@dhcp22.suse.cz> (raw)
In-Reply-To: <20170310135807.GI3753@dhcp22.suse.cz>

On Fri 10-03-17 14:58:07, Michal Hocko wrote:
[...]
> This would explain why onlining from the last block actually works but
> to me this sounds like a completely crappy behavior. All we need to
> guarantee AFAICS is that Normal and Movable zones do not overlap. I
> believe there is even no real requirement about ordering of the physical
> memory in Normal vs. Movable zones as long as they do not overlap. But
> let's keep it simple for the start and always enforce the current status
> quo that Normal zone is physically preceeding Movable zone.
> Can somebody explain why we cannot have a simple rule for Normal vs.
> Movable which would be:
> 	- block [pfn, pfn+block_size] can be Normal if
> 	  !zone_populated(MOVABLE) || pfn+block_size < ZONE_MOVABLE->zone_start_pfn
> 	- block [pfn, pfn+block_size] can be Movable if
> 	  !zone_populated(NORMAL) || ZONE_NORMAL->zone_end_pfn < pfn

OK, so while I was playing with this setup some more I probably got why
this is done this way. All new memblocks are added to the zone Normal
where they are accounted as spanned but not present. When we do
online_movable we just cut from the end of the Normal zone and move it
to Movable zone. This sounds really awkward. What was the reason to go
this way? Why cannot we simply add those pages to the zone at the online
time?
-- 
Michal Hocko
SUSE Labs

--
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>

  reply	other threads:[~2017-03-10 15:53 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27  9:28 [RFC PATCH] mm, hotplug: get rid of auto_online_blocks Michal Hocko
2017-02-27 10:02 ` Vitaly Kuznetsov
2017-02-27 10:21   ` Michal Hocko
2017-02-27 10:49     ` Vitaly Kuznetsov
2017-02-27 12:56       ` Michal Hocko
2017-02-27 13:17         ` Vitaly Kuznetsov
2017-02-27 11:25   ` Heiko Carstens
2017-02-27 11:50     ` Vitaly Kuznetsov
2017-02-27 15:43     ` Michal Hocko
2017-02-28 10:21       ` Heiko Carstens
2017-03-02 13:53       ` Igor Mammedov
2017-03-02 14:28         ` Michal Hocko
2017-03-02 17:03           ` Igor Mammedov
2017-03-03  8:27             ` Michal Hocko
2017-03-03 17:34               ` Igor Mammedov
2017-03-06 14:54                 ` Michal Hocko
2017-03-07 12:40                   ` Igor Mammedov
2017-03-09 12:54                     ` Michal Hocko
2017-03-10 13:58                       ` WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks) Michal Hocko
2017-03-10 15:53                         ` Michal Hocko [this message]
2017-03-10 19:00                           ` Reza Arbab
2017-03-13  9:21                             ` Michal Hocko
2017-03-13 14:58                               ` Reza Arbab
2017-03-14 19:35                               ` Andrea Arcangeli
2017-03-15  7:57                                 ` Michal Hocko
2017-03-13 15:11                           ` Michal Hocko
2017-03-13 23:16                             ` Andi Kleen
2017-03-10 17:39                         ` WTH is going on with memory hotplug sysf interface Yasuaki Ishimatsu
2017-03-13  9:19                           ` Michal Hocko
2017-03-14 16:05                             ` YASUAKI ISHIMATSU
2017-03-14 16:20                               ` Michal Hocko
2017-03-13 10:31                         ` WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks) Igor Mammedov
2017-03-13 10:43                           ` Michal Hocko
2017-03-13 13:57                             ` Igor Mammedov
2017-03-13 14:36                               ` Michal Hocko
2017-03-13 10:55                       ` [RFC PATCH] mm, hotplug: get rid of auto_online_blocks Igor Mammedov
2017-03-13 12:28                         ` Michal Hocko
2017-03-13 12:54                           ` Vitaly Kuznetsov
2017-03-13 13:19                             ` Michal Hocko
2017-03-13 13:42                               ` Vitaly Kuznetsov
2017-03-13 14:32                                 ` Michal Hocko
2017-03-13 15:10                                   ` Vitaly Kuznetsov
2017-03-14 13:20                           ` Igor Mammedov
2017-03-15  7:53                             ` Michal Hocko
2017-03-10 22:00                   ` Daniel Kiper
2017-02-27 17:28 ` Reza Arbab
2017-02-27 17:34   ` 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=20170310155333.GN3753@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arbab@linux.vnet.ibm.com \
    --cc=daniel.kiper@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=imammedo@redhat.com \
    --cc=kys@microsoft.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=qiuxishi@huawei.com \
    --cc=rientjes@google.com \
    --cc=slaoub@gmail.com \
    --cc=tangchen@cn.fujitsu.com \
    --cc=toshi.kani@hpe.com \
    --cc=vbabka@suse.cz \
    --cc=vkuznets@redhat.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xieyisheng1@huawei.com \
    --cc=yasu.isimatu@gmail.com \
    --cc=zhenzhang.zhang@huawei.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