| Message ID | 20190122103708.11043-1-osalvador@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm, memory_hotplug: allocate memmap from hotadded memory | expand |
On 22.01.19 11:37, Oscar Salvador wrote: > Hi, > > this is the v2 of the first RFC I sent back then in October [1]. > In this new version I tried to reduce the complexity as much as possible, > plus some clean ups. > > [Testing] > > I have tested it on "x86_64" (small/big memblocks) and on "powerpc". > On both architectures hot-add/hot-remove online/offline operations > worked as expected using vmemmap pages, I have not seen any issues so far. > I wanted to try it out on Hyper-V/Xen, but I did not manage to. > I plan to do so along this week (if time allows). > I would also like to test it on arm64, but I am not sure I can grab > an arm64 box anytime soon. > > [Coverletter]: > > This is another step to make the memory hotplug more usable. The primary > goal of this patchset is to reduce memory overhead of the hot added > memory (at least for SPARSE_VMEMMAP memory model). The current way we use > to populate memmap (struct page array) has two main drawbacks: > > a) it consumes an additional memory until the hotadded memory itself is > onlined and > b) memmap might end up on a different numa node which is especially true > for movable_node configuration. > > a) is problem especially for memory hotplug based memory "ballooning" > solutions when the delay between physical memory hotplug and the > onlining can lead to OOM and that led to introduction of hacks like auto > onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining > policy for the newly added memory")). > > b) can have performance drawbacks. > > I have also seen hot-add operations failing on powerpc due to the fact > that we try to use order-8 pages when populating the memmap array. > Given 64KB base pagesize, that is 16MB. > If we run out of those, we just fail the operation and we cannot add > more memory. > We could fallback to base pages as x86_64 does, but we can do better. > > One way to mitigate all these issues is to simply allocate memmap array > (which is the largest memory footprint of the physical memory hotplug) > from the hotadded memory itself. VMEMMAP memory model allows us to map > any pfn range so the memory doesn't need to be online to be usable > for the array. See patch 3 for more details. In short I am reusing an > existing vmem_altmap which wants to achieve the same thing for nvdim > device memory. > I only had a quick glimpse. I would prefer if the caller of add_memory() can specify whether it would be ok to allocate vmmap from the range. This e.g. allows ACPI dimm code to allocate from the range, however other machanisms (XEN, hyper-v, virtio-mem) can allow it once they actually support it. Also, while s390x standby memory cannot support allocating from the range, virtio-mem could easily support it on s390x. Not sure how such an interface could look like, but I would really like to have control over that on the add_memory() interface, not per arch.
On Fri, Jan 25, 2019 at 09:53:35AM +0100, David Hildenbrand wrote: Hi David, > I only had a quick glimpse. I would prefer if the caller of add_memory() > can specify whether it would be ok to allocate vmmap from the range. > This e.g. allows ACPI dimm code to allocate from the range, however > other machanisms (XEN, hyper-v, virtio-mem) can allow it once they > actually support it. Well, I think this can be done, and it might make more sense, as we would get rid of some other flags to prevent allocating vmemmap besides mhp_restrictions. > > Also, while s390x standby memory cannot support allocating from the > range, virtio-mem could easily support it on s390x. > > Not sure how such an interface could look like, but I would really like > to have control over that on the add_memory() interface, not per arch. Let me try it out and will report back. Btw, since you are a virt-guy, would it be do feasible for you to test the patchset on hyper-v, xen or your virtio-mem driver? Thanks David!
On 29.01.19 09:43, Oscar Salvador wrote: > On Fri, Jan 25, 2019 at 09:53:35AM +0100, David Hildenbrand wrote: > Hi David, > >> I only had a quick glimpse. I would prefer if the caller of add_memory() >> can specify whether it would be ok to allocate vmmap from the range. >> This e.g. allows ACPI dimm code to allocate from the range, however >> other machanisms (XEN, hyper-v, virtio-mem) can allow it once they >> actually support it. > > Well, I think this can be done, and it might make more sense, as we > would get rid of some other flags to prevent allocating vmemmap > besides mhp_restrictions. Maybe we can also start passing a struct to add_memory() to describe such properties. This would avoid having to change all the layers over and over again. We would just have to establish some rules to avoid breaking stuff. E.g. the struct always has to be initialized to 0 so new features won't break any caller not wanting to make use of that. E.g. memory block types (or if we come up with something better) would also have to add new parameters to add_memory() and friends. > >> >> Also, while s390x standby memory cannot support allocating from the >> range, virtio-mem could easily support it on s390x. >> >> Not sure how such an interface could look like, but I would really like >> to have control over that on the add_memory() interface, not per arch. > > Let me try it out and will report back. > > Btw, since you are a virt-guy, would it be do feasible for you to test the patchset > on hyper-v, xen or your virtio-mem driver? I don't have a XEN or Hyper-V installation myself. cc-ing Vitaly, maybe he has time end resources to test on Hyper-V. I'll be reworking my virtio-mem prototype soon and try with this patchset than! But this could take a little bit longer as I have tons of other stuff on my plate :) So don't worry about virtio-mem too much for now. > > Thanks David! >
On Tue, Jan 22, 2019 at 11:37:04AM +0100, Oscar Salvador wrote: > I yet have to check a couple of things like creating an accounting item > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that > went in there, testing Hyper-V/Xen to see how they react to the fact that > we are using the beginning of the memory-range for our own purposes, and to > check the thing about gigantic pages + hotplug. > I also have to check that there is no compilation/runtime errors when > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > But before that, I would like to get people's feedback about the overall > design, and ideas/suggestions. just a friendly reminder if some feedback is possible :-)
On Wed 30-01-19 22:52:04, Oscar Salvador wrote: > On Tue, Jan 22, 2019 at 11:37:04AM +0100, Oscar Salvador wrote: > > I yet have to check a couple of things like creating an accounting item > > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that > > went in there, testing Hyper-V/Xen to see how they react to the fact that > > we are using the beginning of the memory-range for our own purposes, and to > > check the thing about gigantic pages + hotplug. > > I also have to check that there is no compilation/runtime errors when > > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > > But before that, I would like to get people's feedback about the overall > > design, and ideas/suggestions. > > just a friendly reminder if some feedback is possible :-) I will be off next week and will not get to this this week.
On Thu, Jan 31, 2019 at 08:23:19AM +0100, Michal Hocko wrote: > On Wed 30-01-19 22:52:04, Oscar Salvador wrote: > > On Tue, Jan 22, 2019 at 11:37:04AM +0100, Oscar Salvador wrote: > > > I yet have to check a couple of things like creating an accounting item > > > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that > > > went in there, testing Hyper-V/Xen to see how they react to the fact that > > > we are using the beginning of the memory-range for our own purposes, and to > > > check the thing about gigantic pages + hotplug. > > > I also have to check that there is no compilation/runtime errors when > > > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > > > But before that, I would like to get people's feedback about the overall > > > design, and ideas/suggestions. > > > > just a friendly reminder if some feedback is possible :-) > > I will be off next week and will not get to this this week. Sure, it can wait. In the meantime I will take the chance to clean up a couple of things. Thanks
On Tue, 22 Jan 2019 11:37:04 +0100 Oscar Salvador <osalvador@suse.de> wrote: > Hi, > > this is the v2 of the first RFC I sent back then in October [1]. > In this new version I tried to reduce the complexity as much as possible, > plus some clean ups. > > [Testing] > > I have tested it on "x86_64" (small/big memblocks) and on "powerpc". > On both architectures hot-add/hot-remove online/offline operations > worked as expected using vmemmap pages, I have not seen any issues so far. > I wanted to try it out on Hyper-V/Xen, but I did not manage to. > I plan to do so along this week (if time allows). > I would also like to test it on arm64, but I am not sure I can grab > an arm64 box anytime soon. Hi Oscar, I ran tests on one of our arm64 machines. Particular machine doesn't actually have the mechanics for hotplug, so was all 'faked', but software wise it's all the same. Upshot, seems to work as expected on arm64 as well. Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Remove currently relies on some out of tree patches (and dirty hacks) due to the usual issue with how arm64 does pfn_valid. It's not even vaguely ready for upstream. I'll aim to post an informational set for anyone else testing in this area (it's more or less just a rebase of the patches from a few years ago). +CC Shameer who has been testing the virtualization side for more details on that, and Robin who is driving forward memory hotplug in general on the arm64 side. Thanks, Jonathan > > [Coverletter]: > > This is another step to make the memory hotplug more usable. The primary > goal of this patchset is to reduce memory overhead of the hot added > memory (at least for SPARSE_VMEMMAP memory model). The current way we use > to populate memmap (struct page array) has two main drawbacks: > > a) it consumes an additional memory until the hotadded memory itself is > onlined and > b) memmap might end up on a different numa node which is especially true > for movable_node configuration. > > a) is problem especially for memory hotplug based memory "ballooning" > solutions when the delay between physical memory hotplug and the > onlining can lead to OOM and that led to introduction of hacks like auto > onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining > policy for the newly added memory")). > > b) can have performance drawbacks. > > I have also seen hot-add operations failing on powerpc due to the fact > that we try to use order-8 pages when populating the memmap array. > Given 64KB base pagesize, that is 16MB. > If we run out of those, we just fail the operation and we cannot add > more memory. > We could fallback to base pages as x86_64 does, but we can do better. > > One way to mitigate all these issues is to simply allocate memmap array > (which is the largest memory footprint of the physical memory hotplug) > from the hotadded memory itself. VMEMMAP memory model allows us to map > any pfn range so the memory doesn't need to be online to be usable > for the array. See patch 3 for more details. In short I am reusing an > existing vmem_altmap which wants to achieve the same thing for nvdim > device memory. > > There is also one potential drawback, though. If somebody uses memory > hotplug for 1G (gigantic) hugetlb pages then this scheme will not work > for them obviously because each memory block will contain reserved > area. Large x86 machines will use 2G memblocks so at least one 1G page > will be available but this is still not 2G... > > I am not really sure somebody does that and how reliable that can work > actually. Nevertheless, I _believe_ that onlining more memory into > virtual machines is much more common usecase. Anyway if there ever is a > strong demand for such a usecase we have basically 3 options a) enlarge > memory blocks even more b) enhance altmap allocation strategy and reuse > low memory sections to host memmaps of other sections on the same NUMA > node c) have the memmap allocation strategy configurable to fallback to > the current allocation. > > [Overall design]: > > Let us say we hot-add 2GB of memory on a x86_64 (memblock size = 128M). > That is: > > - 16 sections > - 524288 pages > - 8192 vmemmap pages (out of those 524288. We spend 512 pages for each section) > > The range of pages is: 0xffffea0004000000 - 0xffffea0006000000 > The vmemmap range is: 0xffffea0004000000 - 0xffffea0004080000 > > 0xffffea0004000000 is the head vmemmap page (first page), while all the others > are "tails". > > We keep the following information in it: > > - Head page: > - head->_refcount: number of sections > - head->private : number of vmemmap pages > - Tail page: > - tail->freelist : pointer to the head > > This is done because it eases the work in cases where we have to compute the > number of vmemmap pages to know how much do we have to skip etc, and to keep > the right accounting to present_pages. > > When we want to hot-remove the range, we need to be careful because the first > pages of that range, are used for the memmap maping, so if we remove those > first, we would blow up while accessing the others later on. > For that reason we keep the number of sections in head->_refcount, to know how > much do we have to defer the free up. > > Since in a hot-remove operation, sections are being removed sequentially, the > approach taken here is that every time we hit free_section_memmap(), we decrease > the refcount of the head. > When it reaches 0, we know that we hit the last section, so we call > vmemmap_free() for the whole memory-range in backwards, so we make sure that > the pages used for the mapping will be latest to be freed up. > > The accounting is as follows: > > Vmemmap pages are charged to spanned/present_paged, but not to manages_pages. > > I yet have to check a couple of things like creating an accounting item > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that > went in there, testing Hyper-V/Xen to see how they react to the fact that > we are using the beginning of the memory-range for our own purposes, and to > check the thing about gigantic pages + hotplug. > I also have to check that there is no compilation/runtime errors when > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > But before that, I would like to get people's feedback about the overall > design, and ideas/suggestions. > > > [1] https://patchwork.kernel.org/cover/10685835/ > > Michal Hocko (3): > mm, memory_hotplug: cleanup memory offline path > mm, memory_hotplug: provide a more generic restrictions for memory > hotplug > mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap > > Oscar Salvador (1): > mm, memory_hotplug: allocate memmap from the added memory range for > sparse-vmemmap > > arch/arm64/mm/mmu.c | 10 ++- > arch/ia64/mm/init.c | 5 +- > arch/powerpc/mm/init_64.c | 7 ++ > arch/powerpc/mm/mem.c | 6 +- > arch/s390/mm/init.c | 12 ++- > arch/sh/mm/init.c | 6 +- > arch/x86/mm/init_32.c | 6 +- > arch/x86/mm/init_64.c | 20 +++-- > drivers/hv/hv_balloon.c | 1 + > drivers/xen/balloon.c | 1 + > include/linux/memory_hotplug.h | 42 ++++++++-- > include/linux/memremap.h | 2 +- > include/linux/page-flags.h | 23 +++++ > kernel/memremap.c | 9 +- > mm/compaction.c | 8 ++ > mm/memory_hotplug.c | 186 +++++++++++++++++++++++++++++------------ > mm/page_alloc.c | 47 ++++++++++- > mm/page_isolation.c | 13 +++ > mm/sparse.c | 124 +++++++++++++++++++++++++-- > mm/util.c | 2 + > 20 files changed, 431 insertions(+), 99 deletions(-) >
> -----Original Message----- > From: Jonathan Cameron > Sent: 12 February 2019 12:47 > To: Oscar Salvador <osalvador@suse.de> > Cc: linux-mm@kvack.org; mhocko@suse.com; dan.j.williams@intel.com; > Pavel.Tatashin@microsoft.com; david@redhat.com; > linux-kernel@vger.kernel.org; dave.hansen@intel.com; Shameerali Kolothum > Thodi <shameerali.kolothum.thodi@huawei.com>; Linuxarm > <linuxarm@huawei.com>; Robin Murphy <robin.murphy@arm.com> > Subject: Re: [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from > hotadded memory > > On Tue, 22 Jan 2019 11:37:04 +0100 > Oscar Salvador <osalvador@suse.de> wrote: > > > Hi, > > > > this is the v2 of the first RFC I sent back then in October [1]. > > In this new version I tried to reduce the complexity as much as possible, > > plus some clean ups. > > > > [Testing] > > > > I have tested it on "x86_64" (small/big memblocks) and on "powerpc". > > On both architectures hot-add/hot-remove online/offline operations > > worked as expected using vmemmap pages, I have not seen any issues so far. > > I wanted to try it out on Hyper-V/Xen, but I did not manage to. > > I plan to do so along this week (if time allows). > > I would also like to test it on arm64, but I am not sure I can grab > > an arm64 box anytime soon. > > Hi Oscar, > > I ran tests on one of our arm64 machines. Particular machine doesn't actually > have > the mechanics for hotplug, so was all 'faked', but software wise it's all the > same. > > Upshot, seems to work as expected on arm64 as well. > Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Remove currently relies on some out of tree patches (and dirty hacks) due > to the usual issue with how arm64 does pfn_valid. It's not even vaguely > ready for upstream. I'll aim to post an informational set for anyone else > testing in this area (it's more or less just a rebase of the patches from > a few years ago). > > +CC Shameer who has been testing the virtualization side for more details on > that, Right, I have sent out a RFC series[1] to enable mem hotplug for Qemu ARM virt platform. Using this Qemu, I ran few tests with your patches on a HiSilicon ARM64 platform. Looks like it is doing the job. root@ubuntu:~# uname -a Linux ubuntu 5.0.0-rc1-mm1-00173-g22b0744 #5 SMP PREEMPT Tue Feb 5 10:32:26 GMT 2019 aarch64 aarch64 aarch64 GNU/Linux root@ubuntu:~# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 node 0 size: 981 MB node 0 free: 854 MB node 1 cpus: node 1 size: 0 MB node 1 free: 0 MB node distances: node 0 1 0: 10 20 1: 20 10 root@ubuntu:~# (qemu) (qemu) object_add memory-backend-ram,id=mem1,size=1G (qemu) device_add pc-dimm,id=dimm1,memdev=mem1,node=1 root@ubuntu:~# root@ubuntu:~# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 node 0 size: 981 MB node 0 free: 853 MB node 1 cpus: node 1 size: 1008 MB node 1 free: 1008 MB node distances: node 0 1 0: 10 20 1: 20 10 root@ubuntu:~# FWIW, Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Thanks, Shameer [1] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06966.html and Robin who is driving forward memory hotplug in general on the arm64 > side. > > Thanks, > > Jonathan > > > > > [Coverletter]: > > > > This is another step to make the memory hotplug more usable. The primary > > goal of this patchset is to reduce memory overhead of the hot added > > memory (at least for SPARSE_VMEMMAP memory model). The current way > we use > > to populate memmap (struct page array) has two main drawbacks: > > > > a) it consumes an additional memory until the hotadded memory itself is > > onlined and > > b) memmap might end up on a different numa node which is especially true > > for movable_node configuration. > > > > a) is problem especially for memory hotplug based memory "ballooning" > > solutions when the delay between physical memory hotplug and the > > onlining can lead to OOM and that led to introduction of hacks like auto > > onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining > > policy for the newly added memory")). > > > > b) can have performance drawbacks. > > > > I have also seen hot-add operations failing on powerpc due to the fact > > that we try to use order-8 pages when populating the memmap array. > > Given 64KB base pagesize, that is 16MB. > > If we run out of those, we just fail the operation and we cannot add > > more memory. > > We could fallback to base pages as x86_64 does, but we can do better. > > > > One way to mitigate all these issues is to simply allocate memmap array > > (which is the largest memory footprint of the physical memory hotplug) > > from the hotadded memory itself. VMEMMAP memory model allows us to > map > > any pfn range so the memory doesn't need to be online to be usable > > for the array. See patch 3 for more details. In short I am reusing an > > existing vmem_altmap which wants to achieve the same thing for nvdim > > device memory. > > > > There is also one potential drawback, though. If somebody uses memory > > hotplug for 1G (gigantic) hugetlb pages then this scheme will not work > > for them obviously because each memory block will contain reserved > > area. Large x86 machines will use 2G memblocks so at least one 1G page > > will be available but this is still not 2G... > > > > I am not really sure somebody does that and how reliable that can work > > actually. Nevertheless, I _believe_ that onlining more memory into > > virtual machines is much more common usecase. Anyway if there ever is a > > strong demand for such a usecase we have basically 3 options a) enlarge > > memory blocks even more b) enhance altmap allocation strategy and reuse > > low memory sections to host memmaps of other sections on the same NUMA > > node c) have the memmap allocation strategy configurable to fallback to > > the current allocation. > > > > [Overall design]: > > > > Let us say we hot-add 2GB of memory on a x86_64 (memblock size = 128M). > > That is: > > > > - 16 sections > > - 524288 pages > > - 8192 vmemmap pages (out of those 524288. We spend 512 pages for each > section) > > > > The range of pages is: 0xffffea0004000000 - 0xffffea0006000000 > > The vmemmap range is: 0xffffea0004000000 - 0xffffea0004080000 > > > > 0xffffea0004000000 is the head vmemmap page (first page), while all the > others > > are "tails". > > > > We keep the following information in it: > > > > - Head page: > > - head->_refcount: number of sections > > - head->private : number of vmemmap pages > > - Tail page: > > - tail->freelist : pointer to the head > > > > This is done because it eases the work in cases where we have to compute > the > > number of vmemmap pages to know how much do we have to skip etc, and to > keep > > the right accounting to present_pages. > > > > When we want to hot-remove the range, we need to be careful because the > first > > pages of that range, are used for the memmap maping, so if we remove > those > > first, we would blow up while accessing the others later on. > > For that reason we keep the number of sections in head->_refcount, to know > how > > much do we have to defer the free up. > > > > Since in a hot-remove operation, sections are being removed sequentially, the > > approach taken here is that every time we hit free_section_memmap(), we > decrease > > the refcount of the head. > > When it reaches 0, we know that we hit the last section, so we call > > vmemmap_free() for the whole memory-range in backwards, so we make > sure that > > the pages used for the mapping will be latest to be freed up. > > > > The accounting is as follows: > > > > Vmemmap pages are charged to spanned/present_paged, but not to > manages_pages. > > > > I yet have to check a couple of things like creating an accounting item > > like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the > memory that > > went in there, testing Hyper-V/Xen to see how they react to the fact that > > we are using the beginning of the memory-range for our own purposes, and > to > > check the thing about gigantic pages + hotplug. > > I also have to check that there is no compilation/runtime errors when > > CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. > > But before that, I would like to get people's feedback about the overall > > design, and ideas/suggestions. > > > > > > [1] https://patchwork.kernel.org/cover/10685835/ > > > > Michal Hocko (3): > > mm, memory_hotplug: cleanup memory offline path > > mm, memory_hotplug: provide a more generic restrictions for memory > > hotplug > > mm, sparse: rename kmalloc_section_memmap, > __kfree_section_memmap > > > > Oscar Salvador (1): > > mm, memory_hotplug: allocate memmap from the added memory range > for > > sparse-vmemmap > > > > arch/arm64/mm/mmu.c | 10 ++- > > arch/ia64/mm/init.c | 5 +- > > arch/powerpc/mm/init_64.c | 7 ++ > > arch/powerpc/mm/mem.c | 6 +- > > arch/s390/mm/init.c | 12 ++- > > arch/sh/mm/init.c | 6 +- > > arch/x86/mm/init_32.c | 6 +- > > arch/x86/mm/init_64.c | 20 +++-- > > drivers/hv/hv_balloon.c | 1 + > > drivers/xen/balloon.c | 1 + > > include/linux/memory_hotplug.h | 42 ++++++++-- > > include/linux/memremap.h | 2 +- > > include/linux/page-flags.h | 23 +++++ > > kernel/memremap.c | 9 +- > > mm/compaction.c | 8 ++ > > mm/memory_hotplug.c | 186 > +++++++++++++++++++++++++++++------------ > > mm/page_alloc.c | 47 ++++++++++- > > mm/page_isolation.c | 13 +++ > > mm/sparse.c | 124 > +++++++++++++++++++++++++-- > > mm/util.c | 2 + > > 20 files changed, 431 insertions(+), 99 deletions(-) > > >
On Tue, Feb 12, 2019 at 01:21:38PM +0000, Shameerali Kolothum Thodi wrote: > > Hi Oscar, > > > > I ran tests on one of our arm64 machines. Particular machine doesn't actually > > have > > the mechanics for hotplug, so was all 'faked', but software wise it's all the > > same. > > > > Upshot, seems to work as expected on arm64 as well. > > Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Thanks Jonathan for having given it a spin, much appreciated! I was short of arm64 machines. > (qemu) object_add memory-backend-ram,id=mem1,size=1G > (qemu) device_add pc-dimm,id=dimm1,memdev=mem1,node=1 > root@ubuntu:~# > root@ubuntu:~# numactl -H ... > node 1 cpus: > node 1 size: 1008 MB > node 1 free: 1008 MB > node distances: > node 0 1 > 0: 10 20 > 1: 20 10 > root@ubuntu:~# Ok, this is what I wanted to see. When you hotplugged 1GB, 16MB out of 1024MB were spent for the memmap array, that is why you only see 1008MB there. I am not sure what is the default section size for arm64, but assuming is 128MB, that would make sense as 1GB would mean 8 sections, and each section takes 2MB. That means that at least the mechanism works. > > FWIW, > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> thanks for having tested it ;-)!
On Tue 12-02-19 14:56:58, Oscar Salvador wrote: > On Tue, Feb 12, 2019 at 01:21:38PM +0000, Shameerali Kolothum Thodi wrote: > > > Hi Oscar, > > > > > > I ran tests on one of our arm64 machines. Particular machine doesn't actually > > > have > > > the mechanics for hotplug, so was all 'faked', but software wise it's all the > > > same. > > > > > > Upshot, seems to work as expected on arm64 as well. > > > Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Thanks Jonathan for having given it a spin, much appreciated! > I was short of arm64 machines. > > > (qemu) object_add memory-backend-ram,id=mem1,size=1G > > (qemu) device_add pc-dimm,id=dimm1,memdev=mem1,node=1 > > root@ubuntu:~# > > root@ubuntu:~# numactl -H > ... > > node 1 cpus: > > node 1 size: 1008 MB > > node 1 free: 1008 MB > > node distances: > > node 0 1 > > 0: 10 20 > > 1: 20 10 > > root@ubuntu:~# > > Ok, this is what I wanted to see. > When you hotplugged 1GB, 16MB out of 1024MB were spent > for the memmap array, that is why you only see 1008MB there. > > I am not sure what is the default section size for arm64, but assuming > is 128MB, that would make sense as 1GB would mean 8 sections, > and each section takes 2MB. > > That means that at least the mechanism works. Please make sure to test on a larger machine which has multi section memblocks. This is where I was hitting on bugs hard.
On Tue, Feb 12, 2019 at 03:42:42PM +0100, Michal Hocko wrote: > Please make sure to test on a larger machine which has multi section > memblocks. This is where I was hitting on bugs hard. I tested the patchset with large memblocks (2GB) on x86_64, and worked fine as well. On powerpc I was only able to test it on normal memblocks, but I will check if I can boost the memory there to get large memblocks. And about arm64, I will talk to Jonathan off-list to see if we can do the same. Btw, in the meantime, we could get some parts reviewed perhaps.
Hi, this is the v2 of the first RFC I sent back then in October [1]. In this new version I tried to reduce the complexity as much as possible, plus some clean ups. [Testing] I have tested it on "x86_64" (small/big memblocks) and on "powerpc". On both architectures hot-add/hot-remove online/offline operations worked as expected using vmemmap pages, I have not seen any issues so far. I wanted to try it out on Hyper-V/Xen, but I did not manage to. I plan to do so along this week (if time allows). I would also like to test it on arm64, but I am not sure I can grab an arm64 box anytime soon. [Coverletter]: This is another step to make the memory hotplug more usable. The primary goal of this patchset is to reduce memory overhead of the hot added memory (at least for SPARSE_VMEMMAP memory model). The current way we use to populate memmap (struct page array) has two main drawbacks: a) it consumes an additional memory until the hotadded memory itself is onlined and b) memmap might end up on a different numa node which is especially true for movable_node configuration. a) is problem especially for memory hotplug based memory "ballooning" solutions when the delay between physical memory hotplug and the onlining can lead to OOM and that led to introduction of hacks like auto onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining policy for the newly added memory")). b) can have performance drawbacks. I have also seen hot-add operations failing on powerpc due to the fact that we try to use order-8 pages when populating the memmap array. Given 64KB base pagesize, that is 16MB. If we run out of those, we just fail the operation and we cannot add more memory. We could fallback to base pages as x86_64 does, but we can do better. One way to mitigate all these issues is to simply allocate memmap array (which is the largest memory footprint of the physical memory hotplug) from the hotadded memory itself. VMEMMAP memory model allows us to map any pfn range so the memory doesn't need to be online to be usable for the array. See patch 3 for more details. In short I am reusing an existing vmem_altmap which wants to achieve the same thing for nvdim device memory. There is also one potential drawback, though. If somebody uses memory hotplug for 1G (gigantic) hugetlb pages then this scheme will not work for them obviously because each memory block will contain reserved area. Large x86 machines will use 2G memblocks so at least one 1G page will be available but this is still not 2G... I am not really sure somebody does that and how reliable that can work actually. Nevertheless, I _believe_ that onlining more memory into virtual machines is much more common usecase. Anyway if there ever is a strong demand for such a usecase we have basically 3 options a) enlarge memory blocks even more b) enhance altmap allocation strategy and reuse low memory sections to host memmaps of other sections on the same NUMA node c) have the memmap allocation strategy configurable to fallback to the current allocation. [Overall design]: Let us say we hot-add 2GB of memory on a x86_64 (memblock size = 128M). That is: - 16 sections - 524288 pages - 8192 vmemmap pages (out of those 524288. We spend 512 pages for each section) The range of pages is: 0xffffea0004000000 - 0xffffea0006000000 The vmemmap range is: 0xffffea0004000000 - 0xffffea0004080000 0xffffea0004000000 is the head vmemmap page (first page), while all the others are "tails". We keep the following information in it: - Head page: - head->_refcount: number of sections - head->private : number of vmemmap pages - Tail page: - tail->freelist : pointer to the head This is done because it eases the work in cases where we have to compute the number of vmemmap pages to know how much do we have to skip etc, and to keep the right accounting to present_pages. When we want to hot-remove the range, we need to be careful because the first pages of that range, are used for the memmap maping, so if we remove those first, we would blow up while accessing the others later on. For that reason we keep the number of sections in head->_refcount, to know how much do we have to defer the free up. Since in a hot-remove operation, sections are being removed sequentially, the approach taken here is that every time we hit free_section_memmap(), we decrease the refcount of the head. When it reaches 0, we know that we hit the last section, so we call vmemmap_free() for the whole memory-range in backwards, so we make sure that the pages used for the mapping will be latest to be freed up. The accounting is as follows: Vmemmap pages are charged to spanned/present_paged, but not to manages_pages. I yet have to check a couple of things like creating an accounting item like VMEMMAP_PAGES to show in /proc/meminfo to ease to spot the memory that went in there, testing Hyper-V/Xen to see how they react to the fact that we are using the beginning of the memory-range for our own purposes, and to check the thing about gigantic pages + hotplug. I also have to check that there is no compilation/runtime errors when CONFIG_SPARSEMEM but !CONFIG_SPARSEMEM_VMEMMAP. But before that, I would like to get people's feedback about the overall design, and ideas/suggestions. [1] https://patchwork.kernel.org/cover/10685835/ Michal Hocko (3): mm, memory_hotplug: cleanup memory offline path mm, memory_hotplug: provide a more generic restrictions for memory hotplug mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap Oscar Salvador (1): mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap arch/arm64/mm/mmu.c | 10 ++- arch/ia64/mm/init.c | 5 +- arch/powerpc/mm/init_64.c | 7 ++ arch/powerpc/mm/mem.c | 6 +- arch/s390/mm/init.c | 12 ++- arch/sh/mm/init.c | 6 +- arch/x86/mm/init_32.c | 6 +- arch/x86/mm/init_64.c | 20 +++-- drivers/hv/hv_balloon.c | 1 + drivers/xen/balloon.c | 1 + include/linux/memory_hotplug.h | 42 ++++++++-- include/linux/memremap.h | 2 +- include/linux/page-flags.h | 23 +++++ kernel/memremap.c | 9 +- mm/compaction.c | 8 ++ mm/memory_hotplug.c | 186 +++++++++++++++++++++++++++++------------ mm/page_alloc.c | 47 ++++++++++- mm/page_isolation.c | 13 +++ mm/sparse.c | 124 +++++++++++++++++++++++++-- mm/util.c | 2 + 20 files changed, 431 insertions(+), 99 deletions(-)