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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Tue 14-03-17 14:20:14, Igor Mammedov wrote: > On Mon, 13 Mar 2017 13:28:25 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > > On Thu, 9 Mar 2017 13:54:00 +0100 > > > Michal Hocko wrote: [...] > > > > The kernel is

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Tue 14-03-17 14:20:14, Igor Mammedov wrote: > On Mon, 13 Mar 2017 13:28:25 +0100 > Michal Hocko wrote: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > > On Thu, 9 Mar 2017 13:54:00 +0100 > > > Michal Hocko wrote: [...] > > > > The kernel is supposed to provide a proper API and that

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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 13 Mar 2017 13:28:25 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > On Thu, 9 Mar 2017 13:54:00 +0100 > > Michal Hocko wrote: > > > > [...] > > > > It's major regression if you remove auto online in kernels that >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 13 Mar 2017 13:28:25 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > On Thu, 9 Mar 2017 13:54:00 +0100 > > Michal Hocko wrote: > > > > [...] > > > > It's major regression if you remove auto online in kernels that > > > > run on top of x86 kvm/vmware

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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: >> > >> > What is the API those guests ask for the memory? And who is actually >> > responsible to ask for that memory? Is it a kernel or userspace >> > solution? >> >> Whatever, this can even be a

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: >> > >> > What is the API those guests ask for the memory? And who is actually >> > responsible to ask for that memory? Is it a kernel or userspace >> > solution? >> >> Whatever, this can even be a system administrator

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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > >> Michal Hocko writes: > >> > >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> >> > > > >> >> > >-

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > >> Michal Hocko writes: > >> > >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> >> > > > >> >> > >- suggested RFC is not acceptable from virt

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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> >> > > >> >> > >- suggested RFC is not acceptable from virt point of view >> >> > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> >> > > >> >> > >- suggested RFC is not acceptable from virt point of view >> >> > > as it regresses guests on top of x86

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> > > > >> > >- suggested RFC is not acceptable from virt point of view > >> > > as it regresses guests on top of x86 kvm/vmware

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > >> > > > >> > >- suggested RFC is not acceptable from virt point of view > >> > > as it regresses guests on top of x86 kvm/vmware which > >> > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> > > >> > >- suggested RFC is not acceptable from virt point of view >> > > as it regresses guests on top of x86 kvm/vmware which >> > > both use ACPI based memory hotplug. >> >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: >> > > >> > >- suggested RFC is not acceptable from virt point of view >> > > as it regresses guests on top of x86 kvm/vmware which >> > > both use ACPI based memory hotplug. >> > > >> > >-

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > On Thu, 9 Mar 2017 13:54:00 +0100 > Michal Hocko wrote: > > [...] > > > It's major regression if you remove auto online in kernels that > > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > > while breaking

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > On Thu, 9 Mar 2017 13:54:00 +0100 > Michal Hocko wrote: > > [...] > > > It's major regression if you remove auto online in kernels that > > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > > while breaking useful functionality

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 9 Mar 2017 13:54:00 +0100 Michal Hocko wrote: [...] > > It's major regression if you remove auto online in kernels that > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > while breaking useful functionality doesn't make sense. > > > > I would ACK

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 9 Mar 2017 13:54:00 +0100 Michal Hocko wrote: [...] > > It's major regression if you remove auto online in kernels that > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > while breaking useful functionality doesn't make sense. > > > > I would ACK config option removal

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: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Hey, On Mon, Mar 06, 2017 at 03:54:17PM +0100, Michal Hocko wrote: [...] > So let's discuss the current memory hotplug shortcomings and get rid of > the crud which developed on top. I will start by splitting up the patch > into 3 parts. Do the auto online thing from the HyperV and xen balloning

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Hey, On Mon, Mar 06, 2017 at 03:54:17PM +0100, Michal Hocko wrote: [...] > So let's discuss the current memory hotplug shortcomings and get rid of > the crud which developed on top. I will start by splitting up the patch > into 3 parts. Do the auto online thing from the HyperV and xen balloning

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

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Tue 07-03-17 13:40:04, Igor Mammedov wrote: > On Mon, 6 Mar 2017 15:54:17 +0100 > Michal Hocko wrote: > > > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: [...] > > > in current mainline kernel it triggers following code path: > > > > > > online_pages() > > > ... > > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Tue 07-03-17 13:40:04, Igor Mammedov wrote: > On Mon, 6 Mar 2017 15:54:17 +0100 > Michal Hocko wrote: > > > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: [...] > > > in current mainline kernel it triggers following code path: > > > > > > online_pages() > > > ... > > >if

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 6 Mar 2017 15:54:17 +0100 Michal Hocko wrote: > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > > On Fri, 3 Mar 2017 09:27:23 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > > > On Thu, 2 Mar 2017

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 6 Mar 2017 15:54:17 +0100 Michal Hocko wrote: > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > > On Fri, 3 Mar 2017 09:27:23 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > > > On Thu, 2 Mar 2017 15:28:16 +0100 > > > > Michal Hocko

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > On Fri, 3 Mar 2017 09:27:23 +0100 > Michal Hocko wrote: > > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > > On Thu, 2 Mar 2017 15:28:16 +0100 > > > Michal Hocko wrote: > > > > > > > On Thu 02-03-17

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > On Fri, 3 Mar 2017 09:27:23 +0100 > Michal Hocko wrote: > > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > > On Thu, 2 Mar 2017 15:28:16 +0100 > > > Michal Hocko wrote: > > > > > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri, 3 Mar 2017 09:27:23 +0100 Michal Hocko wrote: > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > On Thu, 2 Mar 2017 15:28:16 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > > [...] > > > > When

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri, 3 Mar 2017 09:27:23 +0100 Michal Hocko wrote: > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > On Thu, 2 Mar 2017 15:28:16 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > > [...] > > > > When trying to support memory unplug on guest

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > On Thu, 2 Mar 2017 15:28:16 +0100 > Michal Hocko wrote: > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > [...] > > > When trying to support memory unplug on guest side in RHEL7, > > > experience shows otherwise.

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > On Thu, 2 Mar 2017 15:28:16 +0100 > Michal Hocko wrote: > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > [...] > > > When trying to support memory unplug on guest side in RHEL7, > > > experience shows otherwise. Simplistic udev rule which

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines > > added block doesn't work in

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines > > added block doesn't work in case one wants to

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 14:53:48, Igor Mammedov wrote: [...] > When trying to support memory unplug on guest side in RHEL7, > experience shows otherwise. Simplistic udev rule which onlines > added block doesn't work in case one wants to online it as movable. > > Hotplugged blocks in current kernel should

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 14:53:48, Igor Mammedov wrote: [...] > When trying to support memory unplug on guest side in RHEL7, > experience shows otherwise. Simplistic udev rule which onlines > added block doesn't work in case one wants to online it as movable. > > Hotplugged blocks in current kernel should

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 16:43:04, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > > want for all

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 16:43:04, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > > want for all

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 04:43:04PM +0100, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 04:43:04PM +0100, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote: diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 134a2f69c21a..a72f7f64ee26 100644 --- a/include/linux/memory_hotplug.h +++ b/include/linux/memory_hotplug.h @@ -100,8 +100,6 @@ extern void

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote: diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 134a2f69c21a..a72f7f64ee26 100644 --- a/include/linux/memory_hotplug.h +++ b/include/linux/memory_hotplug.h @@ -100,8 +100,6 @@ extern void

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:28:52, Reza Arbab wrote: > On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote: > >diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > >index 134a2f69c21a..a72f7f64ee26 100644 > >--- a/include/linux/memory_hotplug.h > >+++

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:28:52, Reza Arbab wrote: > On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote: > >diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > >index 134a2f69c21a..a72f7f64ee26 100644 > >--- a/include/linux/memory_hotplug.h > >+++

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > A couple of other thoughts: > > 1) Having all newly added memory online ASAP is probably what people > > want for all virtual machines. > > This is not true for s390. On s390 we

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > A couple of other thoughts: > > 1) Having all newly added memory online ASAP is probably what people > > want for all virtual machines. > > This is not true for s390. On s390 we

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > > [...] > >> I don't have anything new to add to the discussion happened last week > >> but I'd like to summarize my arguments against this

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > > [...] > >> I don't have anything new to add to the discussion happened last week > >> but I'd like to summarize my arguments against this change: > >> > >> 1)

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: >> > [...] >> >> I don't have anything new to add to the discussion happened last week >> >> but I'd

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 27-02-17 11:49:43, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: >> > [...] >> >> I don't have anything new to add to the discussion happened last week >> >> but I'd like to summarize my arguments against

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Heiko Carstens writes: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: >> A couple of other thoughts: >> 1) Having all newly added memory online ASAP is probably what people >> want for all virtual machines. Sorry, obviously missed 'x86' in the

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Heiko Carstens writes: > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: >> A couple of other thoughts: >> 1) Having all newly added memory online ASAP is probably what people >> want for all virtual machines. Sorry, obviously missed 'x86' in the above statement. > > This is

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > A couple of other thoughts: > 1) Having all newly added memory online ASAP is probably what people > want for all virtual machines. This is not true for s390. On s390 we have "standby" memory that a guest sees and potentially may

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > A couple of other thoughts: > 1) Having all newly added memory online ASAP is probably what people > want for all virtual machines. This is not true for s390. On s390 we have "standby" memory that a guest sees and potentially may

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > [...] >> I don't have anything new to add to the discussion happened last week >> but I'd like to summarize my arguments against this change: >> >> 1) This patch doesn't solve any issue. Configuration

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: > [...] >> I don't have anything new to add to the discussion happened last week >> but I'd like to summarize my arguments against this change: >> >> 1) This patch doesn't solve any issue. Configuration option is not an >>

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: [...] > I don't have anything new to add to the discussion happened last week > but I'd like to summarize my arguments against this change: > > 1) This patch doesn't solve any issue. Configuration option is not an > issue by itself, it is an

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 11:02:09, Vitaly Kuznetsov wrote: [...] > I don't have anything new to add to the discussion happened last week > but I'd like to summarize my arguments against this change: > > 1) This patch doesn't solve any issue. Configuration option is not an > issue by itself, it is an

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > From: Michal Hocko > > This knob has been added by 31bc3858ea3e ("memory-hotplug: add automatic > onlining policy for the newly added memory") mainly to cover memory > hotplug based balooning solutions currently implemented for HyperV >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

Michal Hocko writes: > From: Michal Hocko > > This knob has been added by 31bc3858ea3e ("memory-hotplug: add automatic > onlining policy for the newly added memory") mainly to cover memory > hotplug based balooning solutions currently implemented for HyperV > and Xen. Both of them want to

[RFC PATCH] mm, hotplug: get rid of auto_online_blocks

From: Michal Hocko This knob has been added by 31bc3858ea3e ("memory-hotplug: add automatic onlining policy for the newly added memory") mainly to cover memory hotplug based balooning solutions currently implemented for HyperV and Xen. Both of them want to online the memory as

[RFC PATCH] mm, hotplug: get rid of auto_online_blocks

From: Michal Hocko This knob has been added by 31bc3858ea3e ("memory-hotplug: add automatic onlining policy for the newly added memory") mainly to cover memory hotplug based balooning solutions currently implemented for HyperV and Xen. Both of them want to online the memory as soon after