All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Muchun Song <songmuchun@bytedance.com>,
	akpm@linux-foundation.org, mhocko@suse.cz
Cc: n-horiguchi@ah.jp.nec.com, ak@linux.intel.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
Date: Mon, 11 Jan 2021 17:20:51 -0800	[thread overview]
Message-ID: <c61cdf1d-2feb-ecb3-393d-ca25175c73f4@oracle.com> (raw)
In-Reply-To: <20210110124017.86750-5-songmuchun@bytedance.com>

On 1/10/21 4:40 AM, Muchun Song wrote:
> There is a race between dissolve_free_huge_page() and put_page(),
> and the race window is quite small. Theoretically, we should return
> -EBUSY when we encounter this race. In fact, we have a chance to
> successfully dissolve the page if we do a retry. Because the race
> window is quite small. If we seize this opportunity, it is an
> optimization for increasing the success rate of dissolving page.
> 
> If we free a HugeTLB page from a non-task context, it is deferred
> through a workqueue. In this case, we need to flush the work.
> 
> The dissolve_free_huge_page() can be called from memory hotplug,
> the caller aims to free the HugeTLB page to the buddy allocator
> so that the caller can unplug the page successfully.
> 
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
>  mm/hugetlb.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)

I am unsure about the need for this patch.  The code is OK, there are no
issues with the code.

As mentioned in the commit message, this is an optimization and could
potentially cause a memory offline operation to succeed instead of fail.
However, we are very unlikely to ever exercise this code.  Adding an
optimization that is unlikely to be exercised is certainly questionable.

Memory offline is the only code that could benefit from this optimization.
As someone with more memory offline user experience, what is your opinion
Michal?

-- 
Mike Kravetz

> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4a9011e12175..a176ceed55f1 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1763,10 +1763,11 @@ static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
>   * nothing for in-use hugepages and non-hugepages.
>   * This function returns values like below:
>   *
> - *  -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> - *          (allocated or reserved.)
> - *       0: successfully dissolved free hugepages or the page is not a
> - *          hugepage (considered as already dissolved)
> + *  -EAGAIN: race with __free_huge_page() and can do a retry
> + *  -EBUSY:  failed to dissolved free hugepages or the hugepage is in-use
> + *           (allocated or reserved.)
> + *       0:  successfully dissolved free hugepages or the page is not a
> + *           hugepage (considered as already dissolved)
>   */
>  int dissolve_free_huge_page(struct page *page)
>  {
> @@ -1793,8 +1794,10 @@ int dissolve_free_huge_page(struct page *page)
>  		 * We should make sure that the page is already on the free list
>  		 * when it is dissolved.
>  		 */
> -		if (unlikely(!PageHugeFreed(head)))
> +		if (unlikely(!PageHugeFreed(head))) {
> +			rc = -EAGAIN;
>  			goto out;
> +		}
>  
>  		/*
>  		 * Move PageHWPoison flag from head page to the raw error page,
> @@ -1813,6 +1816,14 @@ int dissolve_free_huge_page(struct page *page)
>  	}
>  out:
>  	spin_unlock(&hugetlb_lock);
> +
> +	/*
> +	 * If the freeing of the HugeTLB page is put on a work queue, we should
> +	 * flush the work before retrying.
> +	 */
> +	if (unlikely(rc == -EAGAIN))
> +		flush_work(&free_hpage_work);
> +
>  	return rc;
>  }
>  
> @@ -1835,7 +1846,12 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
>  
>  	for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
>  		page = pfn_to_page(pfn);
> +retry:
>  		rc = dissolve_free_huge_page(page);
> +		if (rc == -EAGAIN) {
> +			cpu_relax();
> +			goto retry;
> +		}
>  		if (rc)
>  			break;
>  	}
> 

  reply	other threads:[~2021-01-12  1:22 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 12:40 [PATCH v3 0/6] Fix some bugs about HugeTLB code Muchun Song
2021-01-10 12:40 ` [PATCH v3 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one Muchun Song
2021-01-12  9:42   ` Michal Hocko
2021-01-12  9:43     ` [External] " Muchun Song
2021-01-12  9:43       ` Muchun Song
2021-01-12 11:00   ` David Hildenbrand
2021-01-12 11:11     ` David Hildenbrand
2021-01-12 11:27       ` Michal Hocko
2021-01-12 11:34         ` David Hildenbrand
2021-01-12 12:16           ` Michal Hocko
2021-01-12 14:23             ` Michal Hocko
2021-01-12 14:41               ` David Hildenbrand
2021-01-12 14:53                 ` Michal Hocko
2021-01-12 20:12                   ` Mike Kravetz
2021-01-12 13:40       ` [External] " Muchun Song
2021-01-12 13:40         ` Muchun Song
2021-01-12 13:51         ` David Hildenbrand
2021-01-12 14:17           ` Muchun Song
2021-01-12 14:17             ` Muchun Song
2021-01-12 14:28             ` David Hildenbrand
2021-01-12 14:59               ` Muchun Song
2021-01-12 14:59                 ` Muchun Song
2021-01-10 12:40 ` [PATCH v3 2/6] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page Muchun Song
2021-01-11 23:04   ` Mike Kravetz
2021-01-12  9:45   ` Michal Hocko
2021-01-10 12:40 ` [PATCH v3 3/6] mm: hugetlb: fix a race between freeing and dissolving the page Muchun Song
2021-01-12  1:06   ` Mike Kravetz
2021-01-12 10:02   ` Michal Hocko
2021-01-12 10:13     ` [External] " Muchun Song
2021-01-12 10:13       ` Muchun Song
2021-01-12 11:17       ` Michal Hocko
2021-01-12 11:43         ` Muchun Song
2021-01-12 11:43           ` Muchun Song
2021-01-12 12:37           ` Michal Hocko
2021-01-12 15:05             ` Muchun Song
2021-01-12 15:05               ` Muchun Song
2021-01-10 12:40 ` [PATCH v3 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page Muchun Song
2021-01-12  1:20   ` Mike Kravetz [this message]
2021-01-12  8:33     ` Michal Hocko
2021-01-12  9:51       ` [External] " Muchun Song
2021-01-12  9:51         ` Muchun Song
2021-01-12 10:06         ` Michal Hocko
2021-01-12 10:49           ` Muchun Song
2021-01-12 10:49             ` Muchun Song
2021-01-12 11:11             ` Michal Hocko
2021-01-12 11:34               ` Muchun Song
2021-01-12 11:34                 ` Muchun Song
2021-01-10 12:40 ` [PATCH v3 5/6] mm: hugetlb: fix a race between isolating and freeing page Muchun Song
2021-01-10 12:40 ` [PATCH v3 6/6] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active Muchun Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c61cdf1d-2feb-ecb3-393d-ca25175c73f4@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.