On Fri, Nov 05, 2021 at 11:58:15AM +0100, David Hildenbrand wrote:

On 05.11.21 06:50, Naoya Horiguchi wrote:

quoted

Hi,

I updated the unpoison patchset based ou discussions over v2.
Please see individual patches for details of updates.

----- (cover letter copied from v2) -----
Main purpose of this series is to sync unpoison code to recent changes
around how hwpoison code takes page refcount.  Unpoison should work or
simply fail (without crash) if impossible.

The recent works of keeping hwpoison pages in shmem pagecache introduce
a new state of hwpoisoned pages, but unpoison for such pages is not
supported yet with this series.

It seems that soft-offline and unpoison can be used as general purpose
page offline/online mechanism (not in the context of memory error).

I'm not sure what the target use case would be TBH ... for proper memory
offlining/memory hotunplug we have to offline whole memory blocks. For
memory ballooning based mechanisms we simply allocate random free pages
and eventually trigger reclaim to make more random free pages available.
For memory hotunplug via virtio-mem we're using alloc_contig_range() to
allocate ranges of interest we logically unplug.

I heard about it from two people independently and I think that that's maybe
a rough idea, so if no one shows the clear use case or someone logically
shows that we don't need it, I do not head for it.

The only benefit compared to alloc_contig_range() might be that we can
offline smaller chunks -- alloc_contig_range() isn't optimized for
sub-MAX_ORDER granularity yet. But then, alloc_contig_range() should
much rather be extended.

If alloc_contig_range() supports memory offline in arbitrary size of
granurality (including a single page), maybe soft offline can be (partially
I guess) unified to it.

Thanks,
Naoya Horiguchi

Long story short, I'm not sure there is a sane use case for this
"general purpose page offline/online mechanism" ...