All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Muchun Song <songmuchun@bytedance.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages
Date: Thu, 18 Feb 2021 11:09:17 +0100	[thread overview]
Message-ID: <20210218100917.GA4842@localhost.localdomain> (raw)
In-Reply-To: <YC0ve4PP+VTrEEtw@dhcp22.suse.cz>

On Wed, Feb 17, 2021 at 04:00:11PM +0100, Michal Hocko wrote:
> Is this really necessary? dissolve_free_huge_page will take care of this
> and the race windown you are covering is really tiny.

Probably not, I was trying to shrink to race window as much as possible
but the call to dissolve_free_huge_page might be enough.

> > +	nid = page_to_nid(page);
> > +	spin_unlock(&hugetlb_lock);
> > +
> > +	/*
> > +	 * Before dissolving the page, we need to allocate a new one,
> > +	 * so the pool remains stable.
> > +	 */
> > +	new_page = alloc_fresh_huge_page(h, gfp_mask, nid, nmask, NULL);
> 
> wrt. fallback to other zones, I haven't realized that the primary
> usecase is a form of memory offlining (from virt-mem). I am not yet sure
> what the proper behavior is in that case but if breaking hugetlb pools,
> similar to the normal hotplug operation, is viable then this needs a
> special mode. We do not want a random alloc_contig_range user to do the
> same. So for starter I would go with __GFP_THISNODE here.

Ok, makes sense.
__GFP_THISNODE will not allow fallback to other node's zones.
Since we only allow the nid the page belongs to, nodemask should be
NULL, right?

> > +	if (!h)
> > +		/*
> > +		 * The page might have been dissolved from under our feet.
> > +		 * If that is the case, return success as if we dissolved it
> > +		 * ourselves.
> > +		 */
> > +		return true;
> 
> nit I would put the comment above the conditin for both cases. It reads
> more easily that way. At least without { }.

Yes, makes sense.

> Other than that I haven't noticed any surprises.

I did. The 'put_page' call should be placed above, right after getting
the page. Otherwise, refcount == 1 and we will fail to dissolve the
new page if we need to (in case old page fails to be dissolved).
I already fixed that locally.

-- 
Oscar Salvador
SUSE L3


  reply	other threads:[~2021-02-18 10:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 10:08 [PATCH 0/2] Make alloc_contig_range handle Hugetlb pages Oscar Salvador
2021-02-17 10:08 ` [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages Oscar Salvador
2021-02-17 13:30   ` Michal Hocko
2021-02-17 13:36     ` David Hildenbrand
2021-02-17 13:50       ` Michal Hocko
2021-02-17 13:53         ` David Hildenbrand
2021-02-17 13:59           ` Michal Hocko
2021-02-17 14:08             ` David Hildenbrand
2021-02-17 14:14               ` Michal Hocko
2021-02-17 14:23               ` Oscar Salvador
2021-02-17 13:42     ` Oscar Salvador
2021-02-17 15:00   ` Michal Hocko
2021-02-18 10:09     ` Oscar Salvador [this message]
2021-02-18 12:52       ` Michal Hocko
2021-02-18 13:32         ` Oscar Salvador
2021-02-18 13:59           ` Michal Hocko
2021-02-18 16:53             ` Oscar Salvador
2021-02-19  9:05             ` Oscar Salvador
2021-02-19  9:56               ` Michal Hocko
2021-02-19 10:14                 ` Oscar Salvador
2021-02-19 20:00                   ` Mike Kravetz
2021-02-19 10:40                 ` Oscar Salvador
2021-02-19 10:55                   ` Michal Hocko
2021-02-19 11:17                     ` Oscar Salvador
2021-02-19 11:24                       ` Michal Hocko
2021-02-17 10:08 ` [PATCH 2/2] mm: Make alloc_contig_range handle in-use " Oscar Salvador
2021-02-17 13:36   ` Michal Hocko
2021-02-17 13:46     ` Oscar Salvador
2021-02-17 13:54       ` Michal Hocko
2021-02-17 15:06   ` Michal Hocko
2021-02-17 15:27     ` Oscar Salvador
2021-02-17 15:33       ` Michal Hocko
2021-02-18  6:01         ` Oscar Salvador

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=20210218100917.GA4842@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.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.