[lkml]   [2020]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 09/14] mm,hwpoison: rework soft offline for in-use pages
On Tue, Sep 22, 2020 at 03:56:45PM +0200, Oscar Salvador wrote:
> This patch changes the way we set and handle in-use poisoned pages. Until
> now, poisoned pages were released to the buddy allocator, trusting that
> the checks that take place at allocation time would act as a safe net
> and would skip that page.
> This has proved to be wrong, as we got some pfn walkers out there, like
> compaction, that all they care is the page to be in a buddy freelist.
> Although this might not be the only user, having poisoned pages in the
> buddy allocator seems a bad idea as we should only have free pages that
> are ready and meant to be used as such.
> Before explaining the taken approach, let us break down the kind of pages
> we can soft offline.
> - Anonymous THP (after the split, they end up being 4K pages)
> - Hugetlb
> - Order-0 pages (that can be either migrated or invalited)
> * Normal pages (order-0 and anon-THP)
> - If they are clean and unmapped page cache pages, we invalidate
> then by means of invalidate_inode_page().
> - If they are mapped/dirty, we do the isolate-and-migrate dance.
> Either way, do not call put_page directly from those paths.
> Instead, we keep the page and send it to page_handle_poison to perform the
> right handling.
> page_handle_poison sets the HWPoison flag and does the last put_page.
> Down the chain, we placed a check for HWPoison page in
> free_pages_prepare, that just skips any poisoned page, so those pages
> do not end up in any pcplist/freelist.
> After that, we set the refcount on the page to 1 and we increment
> the poisoned pages counter.
> If we see that the check in free_pages_prepare creates trouble, we can
> always do what we do for free pages:
> - wait until the page hits buddy's freelists
> - take it off, and flag it
> The downside of the above approach is that we could race with an
> allocation, so by the time we want to take the page off the buddy, the
> page has been already allocated so we cannot soft offline it.
> But the user could always retry it.
> * Hugetlb pages
> - We isolate-and-migrate them
> After the migration has been successful, we call dissolve_free_huge_page,
> and we set HWPoison on the page if we succeed.
> Hugetlb has a slightly different handling though.
> While for non-hugetlb pages we cared about closing the race with an
> allocation, doing so for hugetlb pages requires quite some additional
> and intrusive code (we would need to hook in free_huge_page and some other
> places).
> So I decided to not make the code overly complicated and just fail
> normally if the page we allocated in the meantime.
> We can always build on top of this.
> As a bonus, because of the way we handle now in-use pages, we no longer
> need the put-as-isolation-migratetype dance, that was guarding for poisoned
> pages to end up in pcplists.
> Signed-off-by: Oscar Salvador <>

Acked-by: Naoya Horiguchi <>
 \ /
  Last update: 2020-09-23 09:31    [W:0.103 / U:26.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site