search for: reserve_additional_memori

Hi All Back in August there was a report of these errors popping up in dmesg, and as far as I can tell it's still unresolved even in the latest kernel. System RAM resource [mem 0xc8000000-0xcfffffff] cannot be added xen_balloon: reserve_additional_memory: add_memory() failed: -17 On this example its running 3.10.20-11.el6.centos.alt.x86_64 To replicate this just disable Dom0 memory

My /var/log/messages log is being flooded with kernel messages showing the following messages Aug 1 11:22:52 host43 kernel: System RAM resource 48000000 - 4fffffff cannot be added Aug 1 11:22:52 host43 kernel: xen_balloon: reserve_additional_memory: add_memory() failed: ?17 Doing a search I found a thread from xen-devel that talks a bit about it. I?m not sure if this is related to the same

Hi, > biting this behavior. The specific > error I''m seeing is > > xen_balloon: reserve_additional_memory: add_memory() failed: -17 > System RAM resource 88000000 - 8fffffff cannot be added > > This is a lab system that I''m actively working on so I can give > whatever info you need or run whatever. Below is the xl info and xl > dmesg output [...]

Hi, I have encountered an apparently benign error on two systems where the dom0 kernel log is flooded with messages like: [52482.163855] System RAM resource [mem 0x1b8000000-0x1bfffffff] cannot be added [52482.163860] xen_balloon: reserve_additional_memory: add_memory() failed: -17 The first line is from drivers/xen/xen-balloon.c, the second from mm/memory_hotplug.c The trigger for the

On 21.08.20 12:34, David Hildenbrand wrote: > Let's reuse the new mechanism to merge system ram resources below the > root. We are the only one hotplugging system ram (e.g., DIMMs don't apply), > so this is safe to be used. > > Cc: Andrew Morton <akpm at linux-foundation.org> > Cc: Michal Hocko <mhocko at suse.com> > Cc: Boris Ostrovsky <boris.ostrovsky

Let's reuse the new mechanism to merge system ram resources below the root. We are the only one hotplugging system ram (e.g., DIMMs don't apply), so this is safe to be used. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com> Cc: Juergen Gross <jgross at suse.com> Cc: Stefano

Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com> Cc: Juergen Gross <jgross at suse.com> Cc: Stefano Stabellini

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources" [1] Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Dan Williams

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Reviewed-by: Juergen Gross <jgross at suse.com> # Xen related part Cc: Andrew Morton <akpm at

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches