On Mon, Feb 22, 2021 at 06:31:12PM +0800, Muchun Song wrote:

On Mon, Feb 22, 2021 at 5:25 PM Michal Hocko [off-list ref] wrote:

quoted

On Sat 20-02-21 12:20:36, Muchun Song wrote:

quoted

On Fri, Feb 19, 2021 at 10:12 PM Michal Hocko [off-list ref] wrote:

[...]

quoted

quoted

What about hugetlb page poisoning on HW failure (resp. soft offlining)?

If the HW poisoned hugetlb page failed to be dissolved, the page
will go back to the free list with PG_HWPoison set. But the page
will not be used, because we will check whether the page is HW
poisoned when it is dequeued from the free list. If so, we will skip
this page.

Not really. If the huge page is dissolved, we will take the page out of the
the freelist. See take_page_off_buddy in memory_failure_hugetlb.

In an ideal world, we should inspect that page in free_pages_prepare(),
remove the HPWpoisoned page and process the others, without letting that
page hit Buddy.
And not only for hugetlb, but for any higher order page.
See how memory_failure() happily disengage itself when it finds a higher
order page.
It does it because we have the premise that once that page hits Buddy,
it will stay there as the check_new_page guards us.
But this has been proofed to be quite a weak measure, as compaction does
not performs such a check, and so the page can sneak in.

I fixed that for soft-offline, and for memory-failure in some cases, but more
needs to be done and is it in my TODO list.

quoted

Can this lead to an under provisioned pool then? Or is there a new
hugetlb allocated to replace the poisoned one?

Actually, no page will be allocated. Your concern is right. But without
this patch, the result does not change. e.g. The HW poisoned page
can fail to be dissolved when h->free_huge_pages is equal to
h->resv_huge_pages. But no one seems to have reported this issue so
far. Maybe this behavior needs improvement in the feature.

Yes, something to improve.
I shall have a look.

-- 
Oscar Salvador
SUSE L3