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 10:52:31 +0200 [thread overview] Message-ID: <20170529085231.GE19725@dhcp22.suse.cz> (raw) In-Reply-To: <20170526122509.GB14849@osiris> On Fri 26-05-17 14:25:09, Heiko Carstens wrote: > On Wed, May 24, 2017 at 10:39:57AM +0200, Michal Hocko wrote: > > On Wed 24-05-17 10:20:22, Heiko Carstens wrote: > > > 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? > > 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* > By the way: we played around a bit with the changes wrt memory > hotplug. There are a two odd things: > > 1) With the new code I can generate overlapping zones for ZONE_DMA and > ZONE_NORMAL: > > --- new code: > > DMA [mem 0x0000000000000000-0x000000007fffffff] > Normal [mem 0x0000000080000000-0x000000017fffffff] > > # cat /sys/devices/system/memory/block_size_bytes > 10000000 > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > # echo 0 > /sys/devices/system/memory/memory5/online > # cat /sys/devices/system/memory/memory5/valid_zones > Normal > # echo 1 > /sys/devices/system/memory/memory5/online > Normal OK, interesting. I will double check the code. > # cat /proc/zoneinfo > Node 0, zone DMA > spanned 524288 <----- > present 458752 > managed 455078 > start_pfn: 0 <----- > > Node 0, zone Normal > spanned 720896 > present 589824 > managed 571648 > start_pfn: 327680 <----- > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > this restriction is gone? > > --- old code: > > # echo 0 > /sys/devices/system/memory/memory5/online > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > # echo online_movable > /sys/devices/system/memory/memory5/state > -bash: echo: write error: Invalid argument > # echo online_kernel > /sys/devices/system/memory/memory5/state > -bash: echo: write error: Invalid argument > # echo online > /sys/devices/system/memory/memory5/state > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > > > 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. -- 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 10:52:31 +0200 [thread overview] Message-ID: <20170529085231.GE19725@dhcp22.suse.cz> (raw) In-Reply-To: <20170526122509.GB14849@osiris> On Fri 26-05-17 14:25:09, Heiko Carstens wrote: > On Wed, May 24, 2017 at 10:39:57AM +0200, Michal Hocko wrote: > > On Wed 24-05-17 10:20:22, Heiko Carstens wrote: > > > 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? > > 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* > By the way: we played around a bit with the changes wrt memory > hotplug. There are a two odd things: > > 1) With the new code I can generate overlapping zones for ZONE_DMA and > ZONE_NORMAL: > > --- new code: > > DMA [mem 0x0000000000000000-0x000000007fffffff] > Normal [mem 0x0000000080000000-0x000000017fffffff] > > # cat /sys/devices/system/memory/block_size_bytes > 10000000 > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > # echo 0 > /sys/devices/system/memory/memory5/online > # cat /sys/devices/system/memory/memory5/valid_zones > Normal > # echo 1 > /sys/devices/system/memory/memory5/online > Normal OK, interesting. I will double check the code. > # cat /proc/zoneinfo > Node 0, zone DMA > spanned 524288 <----- > present 458752 > managed 455078 > start_pfn: 0 <----- > > Node 0, zone Normal > spanned 720896 > present 589824 > managed 571648 > start_pfn: 327680 <----- > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > this restriction is gone? > > --- old code: > > # echo 0 > /sys/devices/system/memory/memory5/online > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > # echo online_movable > /sys/devices/system/memory/memory5/state > -bash: echo: write error: Invalid argument > # echo online_kernel > /sys/devices/system/memory/memory5/state > -bash: echo: write error: Invalid argument > # echo online > /sys/devices/system/memory/memory5/state > # cat /sys/devices/system/memory/memory5/valid_zones > DMA > > > 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. -- 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 8:52 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 [this message] 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=20170529085231.GE19725@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: linkBe 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.