search for: mem_cancel_offlin

On Tue 22-10-19 16:02:09, David Hildenbrand wrote: [...] > >>> MEM_CANCEL_OFFLINE could gain the reference back to balance the > >>> MEM_GOING_OFFLINE step. > >> > >> The pages are already unisolated and could be used by the buddy. But again, > >> I think you have an idea that tries to avoid putting pages to the buddy. > > > >...

On Tue 22-10-19 16:02:09, David Hildenbrand wrote: [...] > >>> MEM_CANCEL_OFFLINE could gain the reference back to balance the > >>> MEM_GOING_OFFLINE step. > >> > >> The pages are already unisolated and could be used by the buddy. But again, > >> I think you have an idea that tries to avoid putting pages to the buddy. > > > >...

...#39;t put the pages back to the buddy and don't > implement something like I have in this patch, we'll loop/fail here. > Especially if we have pages with PG_offline + refcount >= 1 . You should have your reference count 0 at this stage as it is after MEM_GOING_OFFLINE. > > MEM_CANCEL_OFFLINE could gain the reference back to balance the > > MEM_GOING_OFFLINE step. > > The pages are already unisolated and could be used by the buddy. But again, > I think you have an idea that tries to avoid putting pages to the buddy. Yeah, set_page_count(page, 0) if you do not want to r...

...#39;t put the pages back to the buddy and don't > implement something like I have in this patch, we'll loop/fail here. > Especially if we have pages with PG_offline + refcount >= 1 . You should have your reference count 0 at this stage as it is after MEM_GOING_OFFLINE. > > MEM_CANCEL_OFFLINE could gain the reference back to balance the > > MEM_GOING_OFFLINE step. > > The pages are already unisolated and could be used by the buddy. But again, > I think you have an idea that tries to avoid putting pages to the buddy. Yeah, set_page_count(page, 0) if you do not want to r...

On 23.10.19 11:43, Michal Hocko wrote: > On Tue 22-10-19 16:02:09, David Hildenbrand wrote: > [...] >>>>> MEM_CANCEL_OFFLINE could gain the reference back to balance the >>>>> MEM_GOING_OFFLINE step. >>>> >>>> The pages are already unisolated and could be used by the buddy. But again, >>>> I think you have an idea that tries to avoid putting pages to the buddy. >>...

...g to > migrate such an unmovable page. So there should be no observable change. > Same applies to balloon compaction users (movable PageOffline() pages), the > pages will simply be migrated. > > Note 1: If offlining fails, a driver has to increment the reference > count again in MEM_CANCEL_OFFLINE. > > Note 2: A driver that makes use of this has to be aware that re-onlining > the memory block has to be handled by hooking into onlining code > (online_page_callback_t), resetting the page PageOffline() and > not giving them to the buddy. > > Cc: Andrew Morton <akpm...

...) scan_movable_pages() ... > > 4a) Memory offlining succeeded: memory_notify(MEM_OFFLINE, &arg); > > Perfect, it worked. Sections are offline. > > 4b) Memory offlining failed > > undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); > memory_notify(MEM_CANCEL_OFFLINE, &arg); Doesn't this return pages back to buddy only when they were marked Buddy already? MEM_CANCEL_OFFLINE could gain the reference back to balance the MEM_GOING_OFFLINE step. One think that I would like to clarify because my previous email could be misleading a bit. You do not really...

...) scan_movable_pages() ... > > 4a) Memory offlining succeeded: memory_notify(MEM_OFFLINE, &arg); > > Perfect, it worked. Sections are offline. > > 4b) Memory offlining failed > > undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); > memory_notify(MEM_CANCEL_OFFLINE, &arg); Doesn't this return pages back to buddy only when they were marked Buddy already? MEM_CANCEL_OFFLINE could gain the reference back to balance the MEM_GOING_OFFLINE step. One think that I would like to clarify because my previous email could be misleading a bit. You do not really...

On Wed 16-10-19 16:14:52, David Hildenbrand wrote: > On 16.10.19 16:03, Michal Hocko wrote: [...] > > But why cannot you keep the reference count at 1 (do get_page when > > offlining the page)? In other words as long as the driver knows the page > > has been returned to the host then it has ref count at 1. Once the page > > is returned to the guest for whatever reason it

On Wed 16-10-19 16:14:52, David Hildenbrand wrote: > On 16.10.19 16:03, Michal Hocko wrote: [...] > > But why cannot you keep the reference count at 1 (do get_page when > > offlining the page)? In other words as long as the driver knows the page > > has been returned to the host then it has ref count at 1. Once the page > > is returned to the guest for whatever reason it

...make offlining fail when trying to migrate such an unmovable page. So there should be no observable change. Same applies to balloon compaction users (movable PageOffline() pages), the pages will simply be migrated. Note 1: If offlining fails, a driver has to increment the reference count again in MEM_CANCEL_OFFLINE. Note 2: A driver that makes use of this has to be aware that re-onlining the memory block has to be handled by hooking into onlining code (online_page_callback_t), resetting the page PageOffline() and not giving them to the buddy. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Ju...

...buddy and don't >> implement something like I have in this patch, we'll loop/fail here. >> Especially if we have pages with PG_offline + refcount >= 1 . > > You should have your reference count 0 at this stage as it is after > MEM_GOING_OFFLINE. > >>> MEM_CANCEL_OFFLINE could gain the reference back to balance the >>> MEM_GOING_OFFLINE step. >> >> The pages are already unisolated and could be used by the buddy. But again, >> I think you have an idea that tries to avoid putting pages to the buddy. > > Yeah, set_page_count(page, 0)...

...make offlining fail when trying to migrate such an unmovable page. So there should be no observable change. Same applies to balloon compaction users (movable PageOffline() pages), the pages will simply be migrated. Note 1: If offlining fails, a driver has to increment the reference count again in MEM_CANCEL_OFFLINE. Note 2: A driver that makes use of this has to be aware that re-onlining the memory block has to be handled by hooking into onlining code (online_page_callback_t), resetting the page PageOffline() and not giving them to the buddy. Reviewed-by: Alexander Duyck <alexander.h.duyck at linux.i...

...make offlining fail when trying to migrate such an unmovable page. So there should be no observable change. Same applies to balloon compaction users (movable PageOffline() pages), the pages will simply be migrated. Note 1: If offlining fails, a driver has to increment the reference count again in MEM_CANCEL_OFFLINE. Note 2: A driver that makes use of this has to be aware that re-onlining the memory block has to be handled by hooking into onlining code (online_page_callback_t), resetting the page PageOffline() and not giving them to the buddy. Reviewed-by: Alexander Duyck <alexander.h.duyck at linux.i...

...g to > migrate such an unmovable page. So there should be no observable change. > Same applies to balloon compaction users (movable PageOffline() pages), the > pages will simply be migrated. > > Note 1: If offlining fails, a driver has to increment the reference > count again in MEM_CANCEL_OFFLINE. > > Note 2: A driver that makes use of this has to be aware that re-onlining > the memory block has to be handled by hooking into onlining code > (online_page_callback_t), resetting the page PageOffline() and > not giving them to the buddy. > > Reviewed-by: Alexander Duy...

...; >> 4a) Memory offlining succeeded: memory_notify(MEM_OFFLINE, &arg); >> >> Perfect, it worked. Sections are offline. >> >> 4b) Memory offlining failed >> >> undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); >> memory_notify(MEM_CANCEL_OFFLINE, &arg); > > Doesn't this return pages back to buddy only when they were marked Buddy > already? Yes, but I think you asked for evaluating what it would take to make the reference count stay at 1 and return the pages to the buddy. I tried to explain the pitfalls of that approac...

On Wed 23-10-19 12:03:51, David Hildenbrand wrote: > >Do you see any downsides? > > The only downside I see is that we get more false negatives on > has_unmovable_pages(), eventually resulting in the offlining stage after > isolation to loop forever (as some PageOffline() pages are not movable > (especially, XEN balloon, HyperV balloon), there won't be progress). >

On Wed 23-10-19 12:03:51, David Hildenbrand wrote: > >Do you see any downsides? > > The only downside I see is that we get more false negatives on > has_unmovable_pages(), eventually resulting in the offlining stage after > isolation to loop forever (as some PageOffline() pages are not movable > (especially, XEN balloon, HyperV balloon), there won't be progress). >

...gt;hotplug_active = true; + virtio_mem_notify_going_offline(vm, mb_id); break; case MEM_GOING_ONLINE: mutex_lock(&vm->hotplug_mutex); @@ -640,6 +688,12 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb, mutex_unlock(&vm->hotplug_mutex); break; case MEM_CANCEL_OFFLINE: + if (!vm->hotplug_active) + break; + virtio_mem_notify_cancel_offline(vm, mb_id); + vm->hotplug_active = false; + mutex_unlock(&vm->hotplug_mutex); + break; case MEM_CANCEL_ONLINE: if (!vm->hotplug_active) break; @@ -666,8 +720,11 @@ static void virtio_mem_set_fak...

...hese pages. I don't see a way to hack around that. > > 3) scan_movable_pages() ... > > 4a) memory_notify(MEM_OFFLINE, &arg); > > Perfect, it worked. Sections are offline. > > 4b) undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); > memory_notify(MEM_CANCEL_OFFLINE, &arg); > > -> Offlining failed for whatever reason. > -> Pages are in the buddy, but we already un-isolated them. BAD. > > By not going via the buddy we avoid these issues and can leave PG_offline > set until the section is fully offline. Something that is very desir...