Received-SPF: pass (google.com: domain of linux-kernel+bounces-7927-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <31b3ced3-953b-49fd-865f-52aa1627e71a@bytedance.com>
Date: Thu, 21 Dec 2023 15:22:42 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot
Content-Language: en-US
To: Mike Kravetz <mike.kravetz@oracle.com>, Gang Li <gang.li@linux.dev>
Cc: David Hildenbrand <david@redhat.com>, David Rientjes
 <rientjes@google.com>, Muchun Song <muchun.song@linux.dev>,
 Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
 linux-kernel@vger.kernel.org
References: <20231208025240.4744-1-gang.li@linux.dev>
 <20231212200653.GA7043@monkey>
From: Gang Li <ligang.bdlg@bytedance.com>
In-Reply-To: <20231212200653.GA7043@monkey>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2023/12/13 04:06, Mike Kravetz wrote:
> With today's code, allocating 6656 2MB pages via the kernel command line
> results in:
> node 0:  924 pages
> node 1: 5732 pages
> total:  6656 pages
> 
> With code to parallel allocations in this series:
> node 0:  924 pages
> node 1: 1547 pages
> total:  2471 pages

Hi Mike,

Disable numa_aware for hugetlb_alloc_node should solve this problem.
I will fix it in v3.