search for: pageofflin

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). > > I somewhat don't like forcing everybody that uses PageOffline() (especially > all users of balloon compaction) to implement memory notifiers just to avoid > that. Maybe, we ev...

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). > > I somewhat don't like forcing everybody that uses PageOffline() (especially > all users of balloon compaction) to implement memory notifiers just to avoid > that. Maybe, we ev...

..._to_page(pfn) > >> somebody: put_page() -> straight to the buddy > > > > Who is that somebody? I thought that it is only the owner/driver to have > > a control over the page. Also the above is not possible as long as the > > owner/driver keeps a reference to the PageOffline page throughout the > > time it is marked that way. > > > > I was reading > > include/linux/mm_types.h: > > "If you want to use the refcount field, it must be used in such a way > that other CPUs temporarily incrementing and then decrementing the >...

..._to_page(pfn) > >> somebody: put_page() -> straight to the buddy > > > > Who is that somebody? I thought that it is only the owner/driver to have > > a control over the page. Also the above is not possible as long as the > > owner/driver keeps a reference to the PageOffline page throughout the > > time it is marked that way. > > > > I was reading > > include/linux/mm_types.h: > > "If you want to use the refcount field, it must be used in such a way > that other CPUs temporarily incrementing and then decrementing the >...

On Mon 02-03-20 14:49:36, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged (allocated via alloc_contig_range()), 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 should > not be handed back to the buddy (which would require clearing PageOffline() > and result in issues if offlining fails and the pages are suddenly in the >...

virtio-mem wants to allow to offline memory blocks of which some parts were unplugged (allocated via alloc_contig_range()), 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 should not be handed back to the buddy (which would require clearing PageOffline() and result in issues if offlining fails and the pages are suddenly in the buddy). Let's a...

virtio-mem wants to allow to offline memory blocks of which some parts were unplugged (allocated via alloc_contig_range()), 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 should not be handed back to the buddy (which would require clearing PageOffline() and result in issues if offlining fails and the pages are suddenly in the buddy). Let's a...

virtio-mem wants to allow to offline memory blocks of which some parts were unplugged (allocated via alloc_contig_range()), 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 should not be handed back to the buddy (which would require clearing PageOffline() and result in issues if offlining fails and the pages are suddenly in the buddy). Let's a...

..., 2020 at 06:14:17PM +0100, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged (allocated via alloc_contig_range()), 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 should > not be handed back to the buddy (which would require clearing PageOffline() > and result in issues if offlining fails and the pages are suddenly in the >...

...incrementing and then decrementing the >> refcount does not cause problems" >> >> And that made me think "anybody can go ahead and try get_page_unless_zero()". >> >> If I am missing something here and this can indeed not happen (e.g., >> because PageOffline() pages are never mapped to user space), then I'll >> happily remove this code. > > The point is that if the owner of the page is holding the only reference > to the page then it is clear that nothing like that's happened. Right, and I think the race I described won't...

...W, >> has_unmovable_pages() has to stop right there if we see one of these pages). > > OK, this is exactly what I was worried about. I can see why you might > want to go an easier way and rule those users out but wouldn't be it > actually more reasonable to explicitly request PageOffline users to > implement MEM_GOING_OFFLINE and prepare their offlined pages for the > offlining operation or fail right there if that is not possible. > If you fail right there during the isolation phase then there is no way > to allow the offlining to proceed from that context. I am not...

...t affect these users (IOW, > has_unmovable_pages() has to stop right there if we see one of these pages). OK, this is exactly what I was worried about. I can see why you might want to go an easier way and rule those users out but wouldn't be it actually more reasonable to explicitly request PageOffline users to implement MEM_GOING_OFFLINE and prepare their offlined pages for the offlining operation or fail right there if that is not possible. 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_not...

...t affect these users (IOW, > has_unmovable_pages() has to stop right there if we see one of these pages). OK, this is exactly what I was worried about. I can see why you might want to go an easier way and rule those users out but wouldn't be it actually more reasonable to explicitly request PageOffline users to implement MEM_GOING_OFFLINE and prepare their offlined pages for the offlining operation or fail right there if that is not possible. 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_not...

...t; 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). >> >> I somewhat don't like forcing everybody that uses PageOffline() (especially >> all users of balloon compaction) to implement memory notifiers just to avoid >>...

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 should not be handed > back to the buddy (which would require clearing PageOffline() and > result in issues if offlining fails and the pages are suddenly in the...

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 should not be handed > back to the buddy (which would require clearing PageOffline() and > result in issues if offlining fails and the pages are suddenly in the...

...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 will never >> get accessed (e.g., when dumping). The pages should not be handed >> back to the buddy (which would require clearing PageOffline() and >> result in issues if offlining fails and the pages are...

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 should not be handed back to the buddy (which would require clearing PageOffline() and result in issues if offlining fails and the pages are suddenly in the buddy). Let's u...

...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 will never >> get accessed (e.g., when dumping). The pages should not be handed >> back to the buddy (which would require clearing PageOffline() and >> result in issues if offlining fails and the pages are...

...gt;> 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 should not be handed >>>> back to the buddy (which would require clearing PageOffline() and >>>> result in issues if of...