search for: pf_offline

...aborted. (see below on the memory isolation notifier) I am assuming that has_unmovable_pages would skip over those pages. Your patch already does that, no? > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> PF_offline must not be cleared so dumping tools will not touch > these pages. There is a time where pages are !PageBuddy() and > !PageOffline(). Well, this is fully under control of the driver, no? Reference count shouldn't play any role here AFAIU. > 3) scan_movable_pages() ... > &g...

...aborted. (see below on the memory isolation notifier) I am assuming that has_unmovable_pages would skip over those pages. Your patch already does that, no? > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> PF_offline must not be cleared so dumping tools will not touch > these pages. There is a time where pages are !PageBuddy() and > !PageOffline(). Well, this is fully under control of the driver, no? Reference count shouldn't play any role here AFAIU. > 3) scan_movable_pages() ... > &g...

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

...gt; -> offline pages with a reference count of one will be detected as unmovable > -> BAD, we abort right away. We could hack around that. > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> BAD, PF_offline must not be cleared so dumping tools will not touch > these 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...

...gt; -> offline pages with a reference count of one will be detected as unmovable > -> BAD, we abort right away. We could hack around that. > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> BAD, PF_offline must not be cleared so dumping tools will not touch > these 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_isolate_page_range() -> offline pages with a reference count of one will be detected as unmovable -> BAD, we abort right away. We could hack around that. 2) memory_notify(MEM_GOING_OFFLINE, &arg); -> Here, we could release all pages to the buddy, clearing PG_offline -> BAD, PF_offline must not be cleared so dumping tools will not touch these 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);...

.... If you fail right there during the isolation phase then there is no way to allow the offlining to proceed from that context. > > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > > > -> Here, we could release all pages to the buddy, clearing PG_offline > > > -> PF_offline must not be cleared so dumping tools will not touch > > > these pages. There is a time where pages are !PageBuddy() and > > > !PageOffline(). > > > > Well, this is fully under control of the driver, no? Reference count > > shouldn't play any role her...

.... If you fail right there during the isolation phase then there is no way to allow the offlining to proceed from that context. > > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > > > -> Here, we could release all pages to the buddy, clearing PG_offline > > > -> PF_offline must not be cleared so dumping tools will not touch > > > these pages. There is a time where pages are !PageBuddy() and > > > !PageOffline(). > > > > Well, this is fully under control of the driver, no? Reference count > > shouldn't play any role her...

...ages with a reference count of one will be detected as unmovable >> -> BAD, we abort right away. We could hack around that. >> >> 2) memory_notify(MEM_GOING_OFFLINE, &arg); >> -> Here, we could release all pages to the buddy, clearing PG_offline >> -> BAD, PF_offline must not be cleared so dumping tools will not touch >> these 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. >> &gt...

...t_isolate_page_range() -> offline pages with a reference count of one will be detected as unmovable -> offlining aborted. (see below on the memory isolation notifier) 2) memory_notify(MEM_GOING_OFFLINE, &arg); -> Here, we could release all pages to the buddy, clearing PG_offline -> PF_offline must not be cleared so dumping tools will not touch these pages. There is a time where pages are !PageBuddy() and !PageOffline(). 3) scan_movable_pages() ... 4a) Memory offlining succeeded: memory_notify(MEM_OFFLINE, &arg); Perfect, it worked. Sections are offline. 4b) Memory offlin...

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

...the offlining to proceed from that context. I am not sure I agree. But let's discuss the details. See below. > >>>> 2) memory_notify(MEM_GOING_OFFLINE, &arg); >>>> -> Here, we could release all pages to the buddy, clearing PG_offline >>>> -> PF_offline must not be cleared so dumping tools will not touch >>>> these pages. There is a time where pages are !PageBuddy() and >>>> !PageOffline(). >>> >>> Well, this is fully under control of the driver, no? Reference count >>> shouldn't pla...

...(HyperV balloon, XEN). We should not affect these users (IOW, has_unmovable_pages() has to stop right there if we see one of these pages). > >> 2) memory_notify(MEM_GOING_OFFLINE, &arg); >> -> Here, we could release all pages to the buddy, clearing PG_offline >> -> PF_offline must not be cleared so dumping tools will not touch >> these pages. There is a time where pages are !PageBuddy() and >> !PageOffline(). > > Well, this is fully under control of the driver, no? Reference count > shouldn't play any role here AFAIU. Yes, this is more...