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: Mon, 29 May 2017 12:45:37 +0200 [thread overview]
Message-ID: <20170529104537.GH19725@dhcp22.suse.cz> (raw)
In-Reply-To: <20170529101128.GA12975@osiris>
On Mon 29-05-17 12:11:28, Heiko Carstens wrote:
> On Mon, May 29, 2017 at 10:52:31AM +0200, Michal Hocko wrote:
> > > Why is it a problem to change the default for 'online'? As far as I can see
> > > that doesn't have too much to do with the order of zones, no?
> >
> > `online' (aka MMOP_ONLINE_KEEP) should always inherit its current zone.
> > The previous implementation made an exception to allow to shift to
> > another zone if it is on the border of two zones. This is what I wanted
> > to get rid of because it is just too ugly to live.
> >
> > But now I am not really sure what is the usecase here. I assume you know
> > how to online the memoery. That's why you had to play tricks with the
> > zones previously. All you need now is to use the proper MMOP_ONLINE*
>
> Yes, however that implies that existing user space has to be changed to
> achieve the same semantics as before. That's the usecase I'm talking about.
Yes that is really unfortunate. It is even more unfortunate how the
original behavior got merged without a deeper consideration.
> On the other hand this change would finally make s390 behave like all other
> architectures, which is certainly not a bad thing. So, while thinking again
> I think you convinced me to agree with this change.
That is definitely good to hear. Btw. I plan to change the semantic even
further. MMOP_ONLINE_KEEP currently ignores movable_node setting and I
plan to change that. Hopefully this won't break more userspace...
> > > 2) Another oddity is that after a memory block was brought online it's
> > > association to ZONE_NORMAL or ZONE_MOVABLE seems to be fixed. Even if it
> > > is brought offline afterwards:
> >
> > This is intended behavior because I got rid of the tricky&ugly zone
> > shifting code. Ultimately I would like to allow for overlapping zones
> > so the explicit online_{movable,kernel} will _always_ work.
>
> Ok, I see. This change (fixed memory block to zone mapping after first
> online) is a bit surprising. On the other hand I can't think of a sane
> usecase why one wants to change the zone a memory block belongs to.
Longeterm I would really like to remove any constrains on where to
online movable or kernel memory. So even if this will be problem it will
be only temporary.
--
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: Mon, 29 May 2017 12:45:37 +0200 [thread overview]
Message-ID: <20170529104537.GH19725@dhcp22.suse.cz> (raw)
In-Reply-To: <20170529101128.GA12975@osiris>
On Mon 29-05-17 12:11:28, Heiko Carstens wrote:
> On Mon, May 29, 2017 at 10:52:31AM +0200, Michal Hocko wrote:
> > > Why is it a problem to change the default for 'online'? As far as I can see
> > > that doesn't have too much to do with the order of zones, no?
> >
> > `online' (aka MMOP_ONLINE_KEEP) should always inherit its current zone.
> > The previous implementation made an exception to allow to shift to
> > another zone if it is on the border of two zones. This is what I wanted
> > to get rid of because it is just too ugly to live.
> >
> > But now I am not really sure what is the usecase here. I assume you know
> > how to online the memoery. That's why you had to play tricks with the
> > zones previously. All you need now is to use the proper MMOP_ONLINE*
>
> Yes, however that implies that existing user space has to be changed to
> achieve the same semantics as before. That's the usecase I'm talking about.
Yes that is really unfortunate. It is even more unfortunate how the
original behavior got merged without a deeper consideration.
> On the other hand this change would finally make s390 behave like all other
> architectures, which is certainly not a bad thing. So, while thinking again
> I think you convinced me to agree with this change.
That is definitely good to hear. Btw. I plan to change the semantic even
further. MMOP_ONLINE_KEEP currently ignores movable_node setting and I
plan to change that. Hopefully this won't break more userspace...
> > > 2) Another oddity is that after a memory block was brought online it's
> > > association to ZONE_NORMAL or ZONE_MOVABLE seems to be fixed. Even if it
> > > is brought offline afterwards:
> >
> > This is intended behavior because I got rid of the tricky&ugly zone
> > shifting code. Ultimately I would like to allow for overlapping zones
> > so the explicit online_{movable,kernel} will _always_ work.
>
> Ok, I see. This change (fixed memory block to zone mapping after first
> online) is a bit surprising. On the other hand I can't think of a sane
> usecase why one wants to change the zone a memory block belongs to.
Longeterm I would really like to remove any constrains on where to
online movable or kernel memory. So even if this will be problem it will
be only temporary.
--
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>
next prev parent reply other threads:[~2017-05-29 10:45 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
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 [this message]
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=20170529104537.GH19725@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.