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 14:32:50 +0100 [thread overview]
Message-ID: <20210218133250.GA7983@localhost.localdomain> (raw)
In-Reply-To: <YC5jFrwegRVkMkBQ@dhcp22.suse.cz>
On Thu, Feb 18, 2021 at 01:52:38PM +0100, Michal Hocko wrote:
> > 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?
>
> I would have to double check because hugetlb has a slightly different
> expectations from nodemask than the page allocator. The later translates
> that to all possible nodes but hugetlb API tries to dereference nodes.
> Maybe THIS node special cases it somewhere.
Uhm, I do not quite follow here.
AFAICS, alloc_fresh_huge_page->alloc_buddy_huge_page does nothing
with the nodemask, bur rather with nodes_retry mask. That is done
to not retry on a node we failed to allocate a page.
Now, alloc_buddy_huge_page calls __alloc_pages_nodemask directly.
If my understanding is correct, it is ok to have a null nodemask
as __next_zones_zonelist() will go through our own zonelist,
since __GFP_THISNODE made us take ZONELIST_NOFALLBACK.
Actually, I do not see how passing a non-null nodemask migth have
helped there, unless we allow to specify more nodes.
> > 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.
>
> I am not sure I follow. newly allocated pages is unreferenced
> unconditionally and the old page is not referenced by this path.
Current code is:
allocate_a_new_page (new_page's refcount = 1)
dissolve_old_page
: if fail
dissolve_new_page (we cannot dissolve it refcount != 0)
put_page(new_page);
It should be:
allocate_a_new_page (new_page's refcount = 1)
put_page(new_page); (new_page's refcount = 0)
dissolve_old_page
: if fail
dissolve_new_page (we can dissolve it as refcount == 0)
I hope this clarifies it .
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-02-18 13:33 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
2021-02-18 12:52 ` Michal Hocko
2021-02-18 13:32 ` Oscar Salvador [this message]
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=20210218133250.GA7983@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.