search for: try_remove_memori

On 16.10.19 15:45, Michal Hocko wrote: > On Wed 16-10-19 14:50:30, David Hildenbrand wrote: >> On 16.10.19 13:43, Michal Hocko wrote: >>> On Thu 19-09-19 16:22:25, David Hildenbrand wrote: >>>> virtio-mem wants to allow to offline memory blocks of which some parts >>>> were unplugged, especially, to later offline and remove completely >>>>

On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >> { >> int rc = 0; >> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, u64 size) >> memblock_remove(start, size); >> } >> >> - __release_memory_resource(start, size); >> + release_mem_region_adjustable(&iomem_resource, start, size); >>

On 15.09.20 11:06, Wei Yang wrote: > On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: >> >>>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >>>> { >>>> int rc = 0; >>>> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, u64 size) >>>> memblock_remove(start, size);

Let's make sure splitting a resource on memory hotunplug will never fail. This will become more relevant once we merge selected system ram resources - then, we'll trigger that case more frequently on memory hotunplug. In general, this function is already unlikely to fail. When we remove memory, we free up quite a lot of metadata (memmap, page tables, memory block device, etc.). The only

On 16.10.19 13:43, Michal Hocko wrote: > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: >> virtio-mem wants to allow to offline memory blocks of which some parts >> were unplugged, especially, to later offline and remove completely >> unplugged memory blocks. The important part is that PageOffline() has >> to remain set until the section is offline, so these pages

Let's make sure splitting a resource on memory hotunplug will never fail. This will become more relevant once we merge selected System RAM resources - then, we'll trigger that case more often on memory hotunplug. In general, this function is already unlikely to fail. When we remove memory, we free up quite a lot of metadata (memmap, page tables, memory block device, etc.). The only reason

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

On Wed 16-10-19 15:45:06, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

On Wed 16-10-19 15:45:06, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

On Tue 25-02-20 15:27:28, David Hildenbrand wrote: > On 25.02.20 15:11, Michal Hocko wrote: > > On Thu 12-12-19 18:11:32, David Hildenbrand wrote: > >> virtio-mem wants to offline and remove a memory block once it unplugged > >> all subblocks (e.g., using alloc_contig_range()). Let's provide > >> an interface to do that from a driver. virtio-mem already

On 16.10.19 13:43, Michal Hocko wrote: > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: >> virtio-mem wants to allow to offline memory blocks of which some parts >> were unplugged, especially, to later offline and remove completely >> unplugged memory blocks. The important part is that PageOffline() has >> to remain set until the section is offline, so these pages

virtio-mem adds memory in memory block granularity, to be able to remove it in the same granularity again later, and to grow slowly on demand. This, however, results in quite a lot of resources when adding a lot of memory. Resources are effectively stored in a list-based tree. Having a lot of resources not only wastes memory, it also makes traversing that tree more expensive, and makes /proc/iomem

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference