All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [-next] memory hotplug regression
Date: Wed, 24 May 2017 10:39:57 +0200	[thread overview]
Message-ID: <20170524083956.GC14733@dhcp22.suse.cz> (raw)
In-Reply-To: <20170524082022.GC5427@osiris>

On Wed 24-05-17 10:20:22, Heiko Carstens wrote:
> Hello Michal,
> 
> I just re-tested linux-next with respect to your memory hotplug changes and
> actually (finally) figured out that your patch ("mm, memory_hotplug: do not
> associate hotadded memory to zones until online)" changes behaviour on
> s390:
> 
> before your patch memory blocks that were offline and located behind the
> last online memory block were added by default to ZONE_MOVABLE:
> 
> # cat /sys/devices/system/memory/memory16/valid_zones
> Movable Normal
> 
> With your patch this changes, so that they will be added to ZONE_NORMAL by
> default instead:
> 
> # cat /sys/devices/system/memory/memory16/valid_zones
> Normal Movable
> 
> Sorry, that I didn't realize this earlier!
>
> Having the ZONE_MOVABLE default was actually the only point why s390's
> arch_add_memory() was rather complex compared to other architectures.
> 
> We always had this behaviour, since we always wanted to be able to offline
> memory after it was brought online. Given that back then "online_movable"
> did not exist, the initial s390 memory hotplug support simply added all
> additional memory to ZONE_MOVABLE.
> 
> Keeping the default the same would be quite important.

Hmm, that is really unfortunate because I would _really_ like to get rid
of the previous semantic which was really awkward. The whole point of
the rework is to get rid of the nasty zone shifting.

Is it an option to use `online_movable' rather than `online' in your setup?
Btw. my long term plan is to remove the zone range constrains altogether
so you could online each memblock to the type you want. Would that be
sufficient for you in general?

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [-next] memory hotplug regression
Date: Wed, 24 May 2017 10:39:57 +0200	[thread overview]
Message-ID: <20170524083956.GC14733@dhcp22.suse.cz> (raw)
In-Reply-To: <20170524082022.GC5427@osiris>

On Wed 24-05-17 10:20:22, Heiko Carstens wrote:
> Hello Michal,
> 
> I just re-tested linux-next with respect to your memory hotplug changes and
> actually (finally) figured out that your patch ("mm, memory_hotplug: do not
> associate hotadded memory to zones until online)" changes behaviour on
> s390:
> 
> before your patch memory blocks that were offline and located behind the
> last online memory block were added by default to ZONE_MOVABLE:
> 
> # cat /sys/devices/system/memory/memory16/valid_zones
> Movable Normal
> 
> With your patch this changes, so that they will be added to ZONE_NORMAL by
> default instead:
> 
> # cat /sys/devices/system/memory/memory16/valid_zones
> Normal Movable
> 
> Sorry, that I didn't realize this earlier!
>
> Having the ZONE_MOVABLE default was actually the only point why s390's
> arch_add_memory() was rather complex compared to other architectures.
> 
> We always had this behaviour, since we always wanted to be able to offline
> memory after it was brought online. Given that back then "online_movable"
> did not exist, the initial s390 memory hotplug support simply added all
> additional memory to ZONE_MOVABLE.
> 
> Keeping the default the same would be quite important.

Hmm, that is really unfortunate because I would _really_ like to get rid
of the previous semantic which was really awkward. The whole point of
the rework is to get rid of the nasty zone shifting.

Is it an option to use `online_movable' rather than `online' in your setup?
Btw. my long term plan is to remove the zone range constrains altogether
so you could online each memblock to the type you want. Would that be
sufficient for you in general?

-- 
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-05-24  8:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24  8:20 [-next] memory hotplug regression Heiko Carstens
2017-05-24  8:20 ` Heiko Carstens
2017-05-24  8:39 ` Michal Hocko [this message]
2017-05-24  8:39   ` Michal Hocko
2017-05-26 12:25   ` Heiko Carstens
2017-05-26 12:25     ` Heiko Carstens
2017-05-29  8:52     ` Michal Hocko
2017-05-29  8:52       ` Michal Hocko
2017-05-29 10:11       ` Heiko Carstens
2017-05-29 10:11         ` Heiko Carstens
2017-05-29 10:45         ` Michal Hocko
2017-05-29 10:45           ` Michal Hocko
2017-05-30 12:18     ` Michal Hocko
2017-05-30 12:18       ` Michal Hocko
2017-05-30 12:37       ` Heiko Carstens
2017-05-30 12:37         ` Heiko Carstens
2017-05-30 14:32         ` Michal Hocko
2017-05-30 14:32           ` Michal Hocko
2017-05-30 14:55           ` Heiko Carstens
2017-05-30 14:55             ` Heiko Carstens
2017-05-30 15:04             ` Michal Hocko
2017-05-30 15:04               ` Michal Hocko
2017-05-31  6:24             ` Michal Hocko
2017-05-31  6:24               ` Michal Hocko
2017-05-31  6:25               ` [PATCH 1/2] mm, memory_hotplug: fix MMOP_ONLINE_KEEP behavior Michal Hocko
2017-05-31  6:25                 ` Michal Hocko
2017-05-31  6:26               ` [PATCH 2/2] mm, memory_hotplug: do not assume ZONE_NORMAL is default kernel zone Michal Hocko
2017-05-31  6:26                 ` Michal Hocko
2017-06-01  6:49               ` [-next] memory hotplug regression Heiko Carstens
2017-06-01  6:49                 ` Heiko Carstens
2017-06-01  7:13                 ` Michal Hocko
2017-06-01  7:13                   ` 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=20170524083956.GC14733@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.