[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190618161151.GB14817@linux>
Date: Tue, 18 Jun 2019 18:11:51 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
xishi.qiuxishi@...baba-inc.com,
"Chen, Jerry T" <jerry.t.chen@...el.com>,
"Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>, linux-kernel@...r.kernel.org,
Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH v3 2/2] mm: hugetlb: soft-offline:
dissolve_free_huge_page() return zero on !PageHuge
On Mon, Jun 17, 2019 at 05:51:16PM +0900, Naoya Horiguchi wrote:
> madvise(MADV_SOFT_OFFLINE) often returns -EBUSY when calling soft offline
> for hugepages with overcommitting enabled. That was caused by the suboptimal
> code in current soft-offline code. See the following part:
>
> ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
> MIGRATE_SYNC, MR_MEMORY_FAILURE);
> if (ret) {
> ...
> } else {
> /*
> * We set PG_hwpoison only when the migration source hugepage
> * was successfully dissolved, because otherwise hwpoisoned
> * hugepage remains on free hugepage list, then userspace will
> * find it as SIGBUS by allocation failure. That's not expected
> * in soft-offlining.
> */
> ret = dissolve_free_huge_page(page);
> if (!ret) {
> if (set_hwpoison_free_buddy_page(page))
> num_poisoned_pages_inc();
> }
> }
> return ret;
Hi Naoya,
just a nit:
>
> Here dissolve_free_huge_page() returns -EBUSY if the migration source page
> was freed into buddy in migrate_pages(), but even in that case we actually
> has a chance that set_hwpoison_free_buddy_page() succeeds. So that means
> current code gives up offlining too early now.
Maybe it is me that I am not really familiar with hugetlb code, but having had
a comment pointing out that the releasing of overcommited hugetlb pages into the
buddy allocator happens in migrate_pages()->put_page()->free_huge_page() would
have been great.
>
> dissolve_free_huge_page() checks that a given hugepage is suitable for
> dissolving, where we should return success for !PageHuge() case because
> the given hugepage is considered as already dissolved.
>
> This change also affects other callers of dissolve_free_huge_page(),
> which are cleaned up together.
>
> Reported-by: Chen, Jerry T <jerry.t.chen@...el.com>
> Tested-by: Chen, Jerry T <jerry.t.chen@...el.com>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
> Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
> Cc: <stable@...r.kernel.org> # v4.19+
Reviewed-by: Oscar Salvador <osalvador@...e.de>
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists