Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote: > Hello, > > On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: > > On Fri 10-03-17 13:00:37, Reza Arbab wrote: > > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > > > >OK, so while I was playing with this setup some

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote: > Hello, > > On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: > > On Fri 10-03-17 13:00:37, Reza Arbab wrote: > > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > > > >OK, so while I was playing with this setup some

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Hello, On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: > On Fri 10-03-17 13:00:37, Reza Arbab wrote: > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > > >OK, so while I was playing with this setup some more I probably got why > > >this is done this way. All new

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Hello, On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: > On Fri 10-03-17 13:00:37, Reza Arbab wrote: > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > > >OK, so while I was playing with this setup some more I probably got why > > >this is done this way. All new

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

> and ARCH_SPARSEMEM_DEFAULT is enabeld on 64b. So I guess whatever was > the reason to add this code back in 2006 is not true anymore. So I am > really wondering. Do we absolutely need to assign pages which are not > onlined yet to the ZONE_NORMAL unconditionally? Why cannot we put them > out of

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

> and ARCH_SPARSEMEM_DEFAULT is enabeld on 64b. So I guess whatever was > the reason to add this code back in 2006 is not true anymore. So I am > really wondering. Do we absolutely need to assign pages which are not > onlined yet to the ZONE_NORMAL unconditionally? Why cannot we put them > out of

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Let's add Andi On Fri 10-03-17 16:53:33, Michal Hocko wrote: > 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

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Let's add Andi On Fri 10-03-17 16:53:33, Michal Hocko wrote: > 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

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: I agree with your general sentiment that this stuff is very nonintuitive. My criterion for nonintuitive is probably different because I would call this _completely_unusable_. Sorry for being so loud about this but the more I look

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: I agree with your general sentiment that this stuff is very nonintuitive. My criterion for nonintuitive is probably different because I would call this _completely_unusable_. Sorry for being so loud about this but the more I look

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 14:57:12, Igor Mammedov wrote: > On Mon, 13 Mar 2017 11:43:02 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > > On Fri, 10 Mar 2017 14:58:07 +0100 > > [...] > > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 14:57:12, Igor Mammedov wrote: > On Mon, 13 Mar 2017 11:43:02 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > > On Fri, 10 Mar 2017 14:58:07 +0100 > > [...] > > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > >

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, 13 Mar 2017 11:43:02 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > On Fri, 10 Mar 2017 14:58:07 +0100 > [...] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, 13 Mar 2017 11:43:02 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > On Fri, 10 Mar 2017 14:58:07 +0100 > [...] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > On Fri, 10 Mar 2017 14:58:07 +0100 [...] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3fff] > > [0.00] ACPI: SRAT: Node 1 PXM 1 [mem

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > On Fri, 10 Mar 2017 14:58:07 +0100 [...] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3fff] > > [0.00] ACPI: SRAT: Node 1 PXM 1 [mem

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri, 10 Mar 2017 14:58:07 +0100 Michal Hocko wrote: > Let's CC people touching this logic. A short summary is that onlining > memory via udev is currently unusable for online_movable because blocks > are added from lower addresses while movable blocks are allowed from >

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri, 10 Mar 2017 14:58:07 +0100 Michal Hocko wrote: > Let's CC people touching this logic. A short summary is that onlining > memory via udev is currently unusable for online_movable because blocks > are added from lower addresses while movable blocks are allowed from > last blocks. More

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri 10-03-17 13:00:37, Reza Arbab wrote: > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > >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

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri 10-03-17 13:00:37, Reza Arbab wrote: > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > >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

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: 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. It's not always zone Normal. See

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: 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. It's not always zone Normal. See

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

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

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

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

WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Let's CC people touching this logic. A short summary is that onlining memory via udev is currently unusable for online_movable because blocks are added from lower addresses while movable blocks are allowed from last blocks. More below. On Thu 09-03-17 13:54:00, Michal Hocko wrote: > On Tue

WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Let's CC people touching this logic. A short summary is that onlining memory via udev is currently unusable for online_movable because blocks are added from lower addresses while movable blocks are allowed from last blocks. More below. On Thu 09-03-17 13:54:00, Michal Hocko wrote: > On Tue