Received-SPF: pass (google.com: domain of linux-kernel+bounces-51498-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <a749cb06-9495-40fc-9192-b019b48eca92@linux.dev>
Date: Sun, 4 Feb 2024 15:48:12 +0800
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PATCH 1/1] hugetlb: fix CONFIG_PADATA dependency for non-SMP
 system
Content-Language: en-US
To: Muchun Song <muchun.song@linux.dev>
Cc: Gang Li <ligang.bdlg@bytedance.com>,
 Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
 linux-mm@kvack.org, Randy Dunlap <rdunlap@infradead.org>,
 kernel test robot <lkp@intel.com>
References: <20240204072525.1986626-1-gang.li@linux.dev>
 <f05f658a-78fa-45cd-ad07-11d87b824702@linux.dev>
From: Gang Li <gang.li@linux.dev>
In-Reply-To: <f05f658a-78fa-45cd-ad07-11d87b824702@linux.dev>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2024/2/4 15:44, Muchun Song wrote:
> I don't think it is a clear way to fix this. If someone want to
> use PADATA in a non-SMP system, he should be carefully to handle
> the non-SMP case himself. I think the better way is to make PADATA
> handle the non-SMP case, I think it should be easy for it, which
> could just call ->thread_fn() many times instead of creating many
> threads in the non-SMP case.
> 
> Thanks.
>

Sounds good, I'll take a look at padata and send a new patch.