* [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma
@ 2020-09-02 2:50 Li Xinhai
2020-09-02 6:14 ` Michal Hocko
0 siblings, 1 reply; 3+ messages in thread
From: Li Xinhai @ 2020-09-02 2:50 UTC (permalink / raw)
To: linux-mm; +Cc: akpm, Roman Gushchin, Mike Kravetz, Michal Hocko
Since commit cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic
hugepages using cma"), the gigantic page would be allocated from node
which is not the preferred node, although there are pages available from
that node. The reason is that the nid parameter has been ignored in
alloc_gigantic_page().
Besides, the __GFP_THISNODE also need be checked if user required to
alloc only from the preferred node.
After this patch, the preferred node is tried first before other allowed
nodes, and don't try to allocate from other nodes if __GFP_THISNODE is
specified. If user don't specify the preferred node, the current node
will be used as preferred node, which makes sure consistent behavior of
allocating gigantic and non-gigantic hugetlb page.
Fixes: cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
Cc: Roman Gushchin <guro@fb.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
---
v2->V3
Consider current node as preferred node if nid is NUMA_NO_NODE, thanks
Mike.
v1->v2:
With review by Mike and Michal, need to check __GFP_THISNODE to avoid
allocate from other nodes.
mm/hugetlb.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a301c2d672bf..5957dc80ebb1 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1250,21 +1250,32 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nodemask)
{
unsigned long nr_pages = 1UL << huge_page_order(h);
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
#ifdef CONFIG_CMA
{
struct page *page;
int node;
- for_each_node_mask(node, *nodemask) {
- if (!hugetlb_cma[node])
- continue;
-
- page = cma_alloc(hugetlb_cma[node], nr_pages,
- huge_page_order(h), true);
+ if (hugetlb_cma[nid]) {
+ page = cma_alloc(hugetlb_cma[nid], nr_pages,
+ huge_page_order(h), true);
if (page)
return page;
}
+
+ if (!(gfp_mask & __GFP_THISNODE)) {
+ for_each_node_mask(node, *nodemask) {
+ if (node == nid || !hugetlb_cma[node])
+ continue;
+
+ page = cma_alloc(hugetlb_cma[node], nr_pages,
+ huge_page_order(h), true);
+ if (page)
+ return page;
+ }
+ }
}
#endif
--
2.18.4
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma
2020-09-02 2:50 [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma Li Xinhai
@ 2020-09-02 6:14 ` Michal Hocko
2020-09-02 18:07 ` Mike Kravetz
0 siblings, 1 reply; 3+ messages in thread
From: Michal Hocko @ 2020-09-02 6:14 UTC (permalink / raw)
To: Li Xinhai; +Cc: linux-mm, akpm, Roman Gushchin, Mike Kravetz
On Wed 02-09-20 10:50:16, Li Xinhai wrote:
> Since commit cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic
> hugepages using cma"), the gigantic page would be allocated from node
> which is not the preferred node, although there are pages available from
> that node. The reason is that the nid parameter has been ignored in
> alloc_gigantic_page().
>
> Besides, the __GFP_THISNODE also need be checked if user required to
> alloc only from the preferred node.
>
> After this patch, the preferred node is tried first before other allowed
> nodes, and don't try to allocate from other nodes if __GFP_THISNODE is
> specified. If user don't specify the preferred node, the current node
> will be used as preferred node, which makes sure consistent behavior of
> allocating gigantic and non-gigantic hugetlb page.
Technically speaking this is still not in full sync with the allocator
semantic. E.g. cma allocator should try nodes in the node distance
order. Possible but not sure how much we really do care for those who
preallocate cma pools. Also __GFP_NOWAIT should skip CMA as that
requires mutex - or even better make alloc_cma gfp aware. Likely few
more things.
If we care then something for a patch or two on its own and also make
the cma part a function on its own to remove the ugly ifdef.
> Fixes: cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
> Cc: Roman Gushchin <guro@fb.com>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> v2->V3
> Consider current node as preferred node if nid is NUMA_NO_NODE, thanks
> Mike.
>
> v1->v2:
> With review by Mike and Michal, need to check __GFP_THISNODE to avoid
> allocate from other nodes.
>
> mm/hugetlb.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a301c2d672bf..5957dc80ebb1 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1250,21 +1250,32 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
> int nid, nodemask_t *nodemask)
> {
> unsigned long nr_pages = 1UL << huge_page_order(h);
> + if (nid == NUMA_NO_NODE)
> + nid = numa_mem_id();
>
> #ifdef CONFIG_CMA
> {
> struct page *page;
> int node;
>
> - for_each_node_mask(node, *nodemask) {
> - if (!hugetlb_cma[node])
> - continue;
> -
> - page = cma_alloc(hugetlb_cma[node], nr_pages,
> - huge_page_order(h), true);
> + if (hugetlb_cma[nid]) {
> + page = cma_alloc(hugetlb_cma[nid], nr_pages,
> + huge_page_order(h), true);
> if (page)
> return page;
> }
> +
> + if (!(gfp_mask & __GFP_THISNODE)) {
> + for_each_node_mask(node, *nodemask) {
> + if (node == nid || !hugetlb_cma[node])
> + continue;
> +
> + page = cma_alloc(hugetlb_cma[node], nr_pages,
> + huge_page_order(h), true);
> + if (page)
> + return page;
> + }
> + }
> }
> #endif
>
> --
> 2.18.4
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma
2020-09-02 6:14 ` Michal Hocko
@ 2020-09-02 18:07 ` Mike Kravetz
0 siblings, 0 replies; 3+ messages in thread
From: Mike Kravetz @ 2020-09-02 18:07 UTC (permalink / raw)
To: Michal Hocko, Li Xinhai; +Cc: linux-mm, akpm, Roman Gushchin
On 9/1/20 11:14 PM, Michal Hocko wrote:
> On Wed 02-09-20 10:50:16, Li Xinhai wrote:
>> Since commit cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic
>> hugepages using cma"), the gigantic page would be allocated from node
>> which is not the preferred node, although there are pages available from
>> that node. The reason is that the nid parameter has been ignored in
>> alloc_gigantic_page().
>>
>> Besides, the __GFP_THISNODE also need be checked if user required to
>> alloc only from the preferred node.
>>
>> After this patch, the preferred node is tried first before other allowed
>> nodes, and don't try to allocate from other nodes if __GFP_THISNODE is
>> specified. If user don't specify the preferred node, the current node
>> will be used as preferred node, which makes sure consistent behavior of
>> allocating gigantic and non-gigantic hugetlb page.
>
> Technically speaking this is still not in full sync with the allocator
> semantic. E.g. cma allocator should try nodes in the node distance
> order. Possible but not sure how much we really do care for those who
> preallocate cma pools. Also __GFP_NOWAIT should skip CMA as that
> requires mutex - or even better make alloc_cma gfp aware. Likely few
> more things.
>
> If we care then something for a patch or two on its own and also make
> the cma part a function on its own to remove the ugly ifdef.
Agreed. There is plenty of room for improvement which can be done with
subsequent changes.
>> Fixes: cf11e85fc08cc6a4 ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
>> Cc: Roman Gushchin <guro@fb.com>
>> Cc: Mike Kravetz <mike.kravetz@oracle.com>
>> Cc: Michal Hocko <mhocko@kernel.org>
>> Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
>
> Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
--
Mike Kravetz
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-09-02 18:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-02 2:50 [PATCH V3] mm/hugetlb: try preferred node first when alloc gigantic page from cma Li Xinhai
2020-09-02 6:14 ` Michal Hocko
2020-09-02 18:07 ` Mike Kravetz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox