search for: pagehwpoison

...pin remains.) > > The refcount released here is from isolate_lru_page() in __soft_offline_page(). > > (the pin by get_any_page is released by put_hwpoison_page just after it.) > > > > .. yes, doing something just after freeing page looks weird, but that's > > how PageHWPoison flag works. IOW, many other page flags are maintained > > only during one "allocate-free" life span, but PageHWPoison still does > > its job beyond it. > > But what prevents the page from being allocated again between put_page() > and test_set_page_hwpoison()? In tha...

...pin remains.) > > The refcount released here is from isolate_lru_page() in __soft_offline_page(). > > (the pin by get_any_page is released by put_hwpoison_page just after it.) > > > > .. yes, doing something just after freeing page looks weird, but that's > > how PageHWPoison flag works. IOW, many other page flags are maintained > > only during one "allocate-free" life span, but PageHWPoison still does > > its job beyond it. > > But what prevents the page from being allocated again between put_page() > and test_set_page_hwpoison()? In tha...

...fcount released here is from isolate_lru_page() in __soft_offline_page(). > >>> (the pin by get_any_page is released by put_hwpoison_page just after it.) > >>> > >>> .. yes, doing something just after freeing page looks weird, but that's > >>> how PageHWPoison flag works. IOW, many other page flags are maintained > >>> only during one "allocate-free" life span, but PageHWPoison still does > >>> its job beyond it. > >> > >> But what prevents the page from being allocated again between put_page() > &gt...

...fcount released here is from isolate_lru_page() in __soft_offline_page(). > >>> (the pin by get_any_page is released by put_hwpoison_page just after it.) > >>> > >>> .. yes, doing something just after freeing page looks weird, but that's > >>> how PageHWPoison flag works. IOW, many other page flags are maintained > >>> only during one "allocate-free" life span, but PageHWPoison still does > >>> its job beyond it. > >> > >> But what prevents the page from being allocated again between put_page() > &gt...

...ion source page to be freed at this put_page() (no pin remains.) The refcount released here is from isolate_lru_page() in __soft_offline_page(). (the pin by get_any_page is released by put_hwpoison_page just after it.) .. yes, doing something just after freeing page looks weird, but that's how PageHWPoison flag works. IOW, many other page flags are maintained only during one "allocate-free" life span, but PageHWPoison still does its job beyond it. As for commenting, this put_page() is called in any MIGRATEPAGE_SUCCESS case (regardless of callers), so what we can say here is "we free t...

...ion source page to be freed at this put_page() (no pin remains.) The refcount released here is from isolate_lru_page() in __soft_offline_page(). (the pin by get_any_page is released by put_hwpoison_page just after it.) .. yes, doing something just after freeing page looks weird, but that's how PageHWPoison flag works. IOW, many other page flags are maintained only during one "allocate-free" life span, but PageHWPoison still does its job beyond it. As for commenting, this put_page() is called in any MIGRATEPAGE_SUCCESS case (regardless of callers), so what we can say here is "we free t...

...>>> The refcount released here is from isolate_lru_page() in __soft_offline_page(). >>> (the pin by get_any_page is released by put_hwpoison_page just after it.) >>> >>> .. yes, doing something just after freeing page looks weird, but that's >>> how PageHWPoison flag works. IOW, many other page flags are maintained >>> only during one "allocate-free" life span, but PageHWPoison still does >>> its job beyond it. >> >> But what prevents the page from being allocated again between put_page() >> and test_set_page_h...

...ed at this put_page() (no pin remains.) > The refcount released here is from isolate_lru_page() in __soft_offline_page(). > (the pin by get_any_page is released by put_hwpoison_page just after it.) > > .. yes, doing something just after freeing page looks weird, but that's > how PageHWPoison flag works. IOW, many other page flags are maintained > only during one "allocate-free" life span, but PageHWPoison still does > its job beyond it. But what prevents the page from being allocated again between put_page() and test_set_page_hwpoison()? In that case we would be markin...

We can already have pages that can be offlined but not allocated in ZONE_MOVABLE - PageHWPoison pages. While these pages can be skipped when offlining ("moving them to /dev/null"), we cannot move them when allocating. virtio-mem managed memory is similar. The logical memory holes corresponding to unplug memory ranges can be skipped when offlining, however, the pages cannot be moved...

...ed at this put_page() (no pin remains.) > The refcount released here is from isolate_lru_page() in __soft_offline_page(). > (the pin by get_any_page is released by put_hwpoison_page just after it.) > > .. yes, doing something just after freeing page looks weird, but that's > how PageHWPoison flag works. IOW, many other page flags are maintained > only during one "allocate-free" life span, but PageHWPoison still does > its job beyond it. Got it. Thanks for the clarification. > > As for commenting, this put_page() is called in any MIGRATEPAGE_SUCCESS > case (r...

...ed at this put_page() (no pin remains.) > The refcount released here is from isolate_lru_page() in __soft_offline_page(). > (the pin by get_any_page is released by put_hwpoison_page just after it.) > > .. yes, doing something just after freeing page looks weird, but that's > how PageHWPoison flag works. IOW, many other page flags are maintained > only during one "allocate-free" life span, but PageHWPoison still does > its job beyond it. Got it. Thanks for the clarification. > > As for commenting, this put_page() is called in any MIGRATEPAGE_SUCCESS > case (r...

...oval_isolated; } /* diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 8d7be3f33e26..baa60222215f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8366,6 +8366,19 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, if ((flags & MEMORY_OFFLINE) && PageHWPoison(page)) continue; + /* + * We treat all PageOffline() pages as movable when offlining + * to give drivers a chance to decrement their reference count + * in MEM_GOING_OFFLINE in order to indicate that these pages + * can be offlined as there are no direct references anymore. + * For...

...oval_isolated; } /* diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 8d7be3f33e26..baa60222215f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8366,6 +8366,19 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, if ((flags & MEMORY_OFFLINE) && PageHWPoison(page)) continue; + /* + * We treat all PageOffline() pages as movable when offlining + * to give drivers a chance to decrement their reference count + * in MEM_GOING_OFFLINE in order to indicate that these pages + * can be offlined as there are no direct references anymore. + * For...

...oval_isolated; } /* diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 64fcaf86763b..6fb3dfca2a97 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8230,6 +8230,19 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, if ((flags & MEMORY_OFFLINE) && PageHWPoison(page)) continue; + /* + * We treat all PageOffline() pages as movable when offlining + * to give drivers a chance to decrement their reference count + * in MEM_GOING_OFFLINE in order to indicate that these pages + * can be offlined as there are no direct references anymore. + * For...

...t; diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 8d7be3f33e26..baa60222215f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8366,6 +8366,19 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, > if ((flags & MEMORY_OFFLINE) && PageHWPoison(page)) > continue; > > + /* > + * We treat all PageOffline() pages as movable when offlining > + * to give drivers a chance to decrement their reference count > + * in MEM_GOING_OFFLINE in order to indicate that these pages > + * can be offlined as there are no d...

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

...t; diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 8d7be3f33e26..baa60222215f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8366,6 +8366,19 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, > if ((flags & MEMORY_OFFLINE) && PageHWPoison(page)) > continue; > > + /* > + * We treat all PageOffline() pages as movable when offlining > + * to give drivers a chance to decrement their reference count > + * in MEM_GOING_OFFLINE in order to indicate that these pages > + * can be offlined as there are no d...

...d_pages) + int flags) { struct page *page; @@ -274,9 +276,16 @@ __test_page_isolated_in_pageblock(unsigned long pfn, unsigned long end_pfn, * simple way to verify that as VM_BUG_ON(), though. */ pfn += 1 << page_order(page); - else if (skip_hwpoisoned_pages && PageHWPoison(page)) + else if ((flags & SKIP_HWPOISON) && PageHWPoison(page)) /* A HWPoisoned page cannot be also PageBuddy */ pfn++; + else if ((flags & SKIP_OFFLINE) && PageOffline(page) && + !page_count(page)) + /* + * Memory devices allow to offline a page i...

Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Let's support partially plugged memory