search for: mem_going_offlin

...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 allow to do that by allowing to isolate any PageOffline() page when offlining. This way, we can reach the memory hotplug notifier MEM_GOING_OFFLINE, where the driver can signal that he is fine with offlining this page by dropping its reference count. PageOffline() pages with a reference count of 0 can then be skipped when offlining the pages (like if they were free, however they are not in the buddy). Anybody who uses PageOffline() pages and...

...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 allow to do that by allowing to isolate any PageOffline() page when offlining. This way, we can reach the memory hotplug notifier MEM_GOING_OFFLINE, where the driver can signal that he is fine with offlining this page by dropping its reference count. PageOffline() pages with a reference count of 0 can then be skipped when offlining the pages (like if they were free, however they are not in the buddy). Anybody who uses PageOffline() pages and...

...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 allow to do that by allowing to isolate any PageOffline() page when offlining. This way, we can reach the memory hotplug notifier MEM_GOING_OFFLINE, where the driver can signal that he is fine with offlining this page by dropping its reference count. PageOffline() pages with a reference count of 0 can then be skipped when offlining the pages (like if they were free, however they are not in the buddy). Anybody who uses PageOffline() pages and...

...dy (which would require clearing PageOffline() > and result in issues if offlining fails and the pages are suddenly in the > buddy). > > Let's allow to do that by allowing to isolate any PageOffline() page > when offlining. This way, we can reach the memory hotplug notifier > MEM_GOING_OFFLINE, where the driver can signal that he is fine with > offlining this page by dropping its reference count. PageOffline() pages > with a reference count of 0 can then be skipped when offlining the > pages (like if they were free, however they are not in the buddy). > > Anybody who use...

...dy (which would require clearing PageOffline() > and result in issues if offlining fails and the pages are suddenly in the > buddy). > > Let's allow to do that by allowing to isolate any PageOffline() page > when offlining. This way, we can reach the memory hotplug notifier > MEM_GOING_OFFLINE, where the driver can signal that he is fine with > offlining this page by dropping its reference count. PageOffline() pages > with a reference count of 0 can then be skipped when offlining the > pages (like if they were free, however they are not in the buddy). > > Anybody who use...

On 02.03.20 18:40, Alexander Duyck wrote: > Reviewed-by: Alexander Duyck <alexander.h.duyck at linux.intel.com> Thanks a lot Alex! -- Thanks, David / dhildenb

On Fri 18-10-19 14:35:06, David Hildenbrand wrote: > On 18.10.19 13:20, Michal Hocko wrote: > > On Fri 18-10-19 10:50:24, David Hildenbrand wrote: > > > On 18.10.19 10:15, Michal Hocko wrote: [...] > > > > for that - MEM_GOING_OFFLINE notification. This sounds like a good place > > > > for the driver to decide whether it is safe to let the page go or not. > > > > > > As I explained, this is too late and fragile. I post again what I posted > > > before with some further explanations > &...

On Fri 18-10-19 14:35:06, David Hildenbrand wrote: > On 18.10.19 13:20, Michal Hocko wrote: > > On Fri 18-10-19 10:50:24, David Hildenbrand wrote: > > > On 18.10.19 10:15, Michal Hocko wrote: [...] > > > > for that - MEM_GOING_OFFLINE notification. This sounds like a good place > > > > for the driver to decide whether it is safe to let the page go or not. > > > > > > As I explained, this is too late and fragile. I post again what I posted > > > before with some further explanations > &...

...s 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 sure I agree. But let's discuss the de...

...ight want to offline/hotremove the whole memory block via sysfs. An elevated reference count would prevent offlining to finish. And I believe this is a good thing because the owner of the offline page might still need to do something to "untrack" that page. We have an interface for that - MEM_GOING_OFFLINE notification. This sounds like a good place for the driver to decide whether it is safe to let the page go or not. If you can let the page go then just drop the reference count. The page is isolated already by that time. If you cannot let it go for whatever reason you can fail the offlining. An a...

...ight want to offline/hotremove the whole memory block via sysfs. An elevated reference count would prevent offlining to finish. And I believe this is a good thing because the owner of the offline page might still need to do something to "untrack" that page. We have an interface for that - MEM_GOING_OFFLINE notification. This sounds like a good place for the driver to decide whether it is safe to let the page go or not. If you can let the page go then just drop the reference count. The page is isolated already by that time. If you cannot let it go for whatever reason you can fail the offlining. An a...

...o do anything to > untrack the page. I mean that's what a reference count of zero actually > means - no direct reference. Will this be the case for other potential users of the similar/same mechanism? I thought that this would become a more spread mechanism. [...] > > for that - MEM_GOING_OFFLINE notification. This sounds like a good place > > for the driver to decide whether it is safe to let the page go or not. > > As I explained, this is too late and fragile. I post again what I posted > before with some further explanations > > __offline_pages() works like this:...

...o do anything to > untrack the page. I mean that's what a reference count of zero actually > means - no direct reference. Will this be the case for other potential users of the similar/same mechanism? I thought that this would become a more spread mechanism. [...] > > for that - MEM_GOING_OFFLINE notification. This sounds like a good place > > for the driver to decide whether it is safe to let the page go or not. > > As I explained, this is too late and fragile. I post again what I posted > before with some further explanations > > __offline_pages() works like this:...

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. > > > > Yeah, set_page_count(page, 0) if you do not want to release that page > >...

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. > > > > Yeah, set_page_count(page, 0) if you do not want to release that page > >...

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). >

...ronize against memory onlining/offlining (e.g., using memory notifiers) while incrementing the reference count. Also, a driver that relies in this feature is aware that re-onlining the memory will require to re-set the pages PageOffline() - e.g., via the online_page_callback_t. > for that - MEM_GOING_OFFLINE notification. This sounds like a good place > for the driver to decide whether it is safe to let the page go or not. As I explained, this is too late and fragile. I post again what I posted before with some further explanations __offline_pages() works like this: 1) start_isolate_page_range(...

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. >>> >>> Yeah, set_page_count(page, 0) if you do not want to release that p...

...compaction instead (because that's what it really is, a balloon driver). I could imagine that HyperV might want to use that in the future. And it should be possible to make them play with the rules. They already use memory notifiers and online_page_callback_t. > >>> for that - MEM_GOING_OFFLINE notification. This sounds like a good place >>> for the driver to decide whether it is safe to let the page go or not. >> >> As I explained, this is too late and fragile. I post again what I posted >> before with some further explanations >> >> __offline_page...