Message ID | 20240102131249.76622-4-gang.li@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp4436014dyb; Tue, 2 Jan 2024 05:14:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IGB6vQgnq2/TD4HThA/wJqCCrv9psL0oprV8KccOA2secy7Rmx0R7T8l0lIeUdcihtxtWQb X-Received: by 2002:a05:622a:14d0:b0:425:918b:f189 with SMTP id u16-20020a05622a14d000b00425918bf189mr23088284qtx.105.1704201252649; Tue, 02 Jan 2024 05:14:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704201252; cv=none; d=google.com; s=arc-20160816; b=oLIGbYxw9KVZcBReP2r23hixh965t1/4EdOiBH/lJ3JTeSip4MLXX4erMNSIFwpjyQ PPkFekfDGOrSxPvJPYAg+/vdH+X8nQ1GTRxKj87WGHDAyLbsl39iRUjljfHtNimCX5hN 134zGRrRUfbWAcFqPKPiEE+xiOT6ZnfJr8SWNuWmETd2h+k2b6j1sKe4RelHfh5Adf5T Bg6U34Q4SgLbkmRbWnjKbKVZt3nW9KG69aLOeI7ir7r7gMI/3fYAj/amY4biO/Z4pB5A 1dos4N99908xpBjDl0ix32Ujb37cYNfKLie8x6Kyx6gTnanqup4vGMiGe722901GQrHv krKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=0BwxzTkbv6fMj2IlVqqVSI+5ecpQCg7jHconULcXMhU=; fh=5n5b5+XOwLgGNDePhvfXysty56rnkWOs9jaHEODdVeE=; b=g+Mvj5Z5A3Ovd3UJOL2K0DySGp6CC2xUh5I4cTZQ9HrHDOrRQjTHC0lB/UBfSXOpG1 Li0Mbe+np8/KdWwe+PDX/OefH0Oe2knayJhx/ti1WgpCue0/L/eQCUnPmBqc4evRbLBU 0BE1eqbjmAmpE5eTglX4PrNFZ/CoemIL/E7pDm1rHHBQDzIi0EpVB5MPVhOaFi1zPxRx w/2kSOK66+TLasSppu2PGf4/vgi4NnhA4kqrcByZ1cfDxazyl4DQI2xB1IpovlI9Pqcv 1+PnrAIxMMW+XakdVqCMshn77Xi9Dej6bbN9EP6T6fYELcejy5J5eZd0/a5CEfzvR9T9 QidA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=Eko96B8O; spf=pass (google.com: domain of linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id 4-20020ac85704000000b00421b95298d8si26914811qtw.404.2024.01.02.05.14.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 05:14:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=Eko96B8O; spf=pass (google.com: domain of linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14384-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 726681C21FE9 for <ouuuleilei@gmail.com>; Tue, 2 Jan 2024 13:14:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9E1BA125CA; Tue, 2 Jan 2024 13:13:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Eko96B8O" X-Original-To: linux-kernel@vger.kernel.org Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 182BC10A0D for <linux-kernel@vger.kernel.org>; Tue, 2 Jan 2024 13:13:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1704201208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0BwxzTkbv6fMj2IlVqqVSI+5ecpQCg7jHconULcXMhU=; b=Eko96B8OaBJVKkDyhD/UM2q4AYrrNykiYUCYNcfOZ1A32BsBy/zQcEdL/Y94CQ0FhNyARP ty7rzZ3ZddQ0yUhcxHQr6aLFHRTzuQy4e+fg9Mn0btG4rccV9gwgX3Wz1I1oA73vy9Mlfb eNChOv/zhRPqCB0SpDniNhAQ6XPQGOE= From: Gang Li <gang.li@linux.dev> To: David Hildenbrand <david@redhat.com>, David Rientjes <rientjes@google.com>, Mike Kravetz <mike.kravetz@oracle.com>, Muchun Song <muchun.song@linux.dev>, Andrew Morton <akpm@linux-foundation.org>, Tim Chen <tim.c.chen@linux.intel.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, ligang.bdlg@bytedance.com, Gang Li <gang.li@linux.dev> Subject: [PATCH v3 3/7] padata: dispatch works on different nodes Date: Tue, 2 Jan 2024 21:12:45 +0800 Message-Id: <20240102131249.76622-4-gang.li@linux.dev> In-Reply-To: <20240102131249.76622-1-gang.li@linux.dev> References: <20240102131249.76622-1-gang.li@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786984532446064889 X-GMAIL-MSGID: 1786984532446064889 |
Series |
hugetlb: parallelize hugetlb page init on boot
|
|
Commit Message
Gang Li
Jan. 2, 2024, 1:12 p.m. UTC
When a group of tasks that access different nodes are scheduled on the
same node, they may encounter bandwidth bottlenecks and access latency.
Thus, numa_aware flag is introduced here, allowing tasks to be
distributed across different nodes to fully utilize the advantage of
multi-node systems.
Signed-off-by: Gang Li <gang.li@linux.dev>
---
include/linux/padata.h | 3 +++
kernel/padata.c | 8 ++++++--
mm/mm_init.c | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
Comments
On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: > When a group of tasks that access different nodes are scheduled on the > same node, they may encounter bandwidth bottlenecks and access latency. > > Thus, numa_aware flag is introduced here, allowing tasks to be > distributed across different nodes to fully utilize the advantage of > multi-node systems. > > Signed-off-by: Gang Li <gang.li@linux.dev> > --- > include/linux/padata.h | 3 +++ > kernel/padata.c | 8 ++++++-- > mm/mm_init.c | 1 + > 3 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/include/linux/padata.h b/include/linux/padata.h > index 495b16b6b4d72..f79ccd50e7f40 100644 > --- a/include/linux/padata.h > +++ b/include/linux/padata.h > @@ -137,6 +137,8 @@ struct padata_shell { > * appropriate for one worker thread to do at once. > * @max_threads: Max threads to use for the job, actual number may be less > * depending on task size and minimum chunk size. > + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but > + * no CPU, dispatch its jobs to a random CPU. > */ > struct padata_mt_job { > void (*thread_fn)(unsigned long start, unsigned long end, void *arg); > @@ -146,6 +148,7 @@ struct padata_mt_job { > unsigned long align; > unsigned long min_chunk; > int max_threads; > + bool numa_aware; > }; > > /** > diff --git a/kernel/padata.c b/kernel/padata.c > index 179fb1518070c..1c2b3a337479e 100644 > --- a/kernel/padata.c > +++ b/kernel/padata.c > @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) > struct padata_work my_work, *pw; > struct padata_mt_job_state ps; > LIST_HEAD(works); > - int nworks; > + int nworks, nid = 0; If we always start from 0, we may be biased towards the low numbered node, and not use high numbered nodes at all. Suggest you do static nid = 0; > > if (job->size == 0) > return; > @@ -517,7 +517,11 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) > ps.chunk_size = roundup(ps.chunk_size, job->align); > > list_for_each_entry(pw, &works, pw_list) > - queue_work(system_unbound_wq, &pw->pw_work); > + if (job->numa_aware) > + queue_work_node((++nid % num_node_state(N_MEMORY)), > + system_unbound_wq, &pw->pw_work); I think we should use nid = next_node(nid, node_states[N_CPU]) instead of ++nid % num_node_state(N_MEMORY). You are picking the next node with CPU to handle the job. Tim > + else > + queue_work(system_unbound_wq, &pw->pw_work); > > /* Use the current thread, which saves starting a workqueue worker. */ > padata_work_init(&my_work, padata_mt_helper, &ps, PADATA_WORK_ONSTACK); > diff --git a/mm/mm_init.c b/mm/mm_init.c > index 89dc29f1e6c6f..59fcffddf65a3 100644 > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -2225,6 +2225,7 @@ static int __init deferred_init_memmap(void *data) > .align = PAGES_PER_SECTION, > .min_chunk = PAGES_PER_SECTION, > .max_threads = max_threads, > + .numa_aware = false, > }; > > padata_do_multithreaded(&job);
On 2024/1/12 01:50, Tim Chen wrote: > On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: >> When a group of tasks that access different nodes are scheduled on the >> same node, they may encounter bandwidth bottlenecks and access latency. >> >> Thus, numa_aware flag is introduced here, allowing tasks to be >> distributed across different nodes to fully utilize the advantage of >> multi-node systems. >> >> Signed-off-by: Gang Li <gang.li@linux.dev> >> --- >> include/linux/padata.h | 3 +++ >> kernel/padata.c | 8 ++++++-- >> mm/mm_init.c | 1 + >> 3 files changed, 10 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/padata.h b/include/linux/padata.h >> index 495b16b6b4d72..f79ccd50e7f40 100644 >> --- a/include/linux/padata.h >> +++ b/include/linux/padata.h >> @@ -137,6 +137,8 @@ struct padata_shell { >> * appropriate for one worker thread to do at once. >> * @max_threads: Max threads to use for the job, actual number may be less >> * depending on task size and minimum chunk size. >> + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but >> + * no CPU, dispatch its jobs to a random CPU. >> */ >> struct padata_mt_job { >> void (*thread_fn)(unsigned long start, unsigned long end, void *arg); >> @@ -146,6 +148,7 @@ struct padata_mt_job { >> unsigned long align; >> unsigned long min_chunk; >> int max_threads; >> + bool numa_aware; >> }; >> >> /** >> diff --git a/kernel/padata.c b/kernel/padata.c >> index 179fb1518070c..1c2b3a337479e 100644 >> --- a/kernel/padata.c >> +++ b/kernel/padata.c >> @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) >> struct padata_work my_work, *pw; >> struct padata_mt_job_state ps; >> LIST_HEAD(works); >> - int nworks; >> + int nworks, nid = 0; > > If we always start from 0, we may be biased towards the low numbered node, > and not use high numbered nodes at all. Suggest you do > static nid = 0; > When we use `static`, if there are multiple parallel calls to `padata_do_multithreaded`, it may result in an uneven distribution of tasks for each padata_do_multithreaded. We can make the following modifications to address this issue. ``` diff --git a/kernel/padata.c b/kernel/padata.c index 1c2b3a337479e..925e48df6dd8d 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -485,7 +485,8 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) struct padata_work my_work, *pw; struct padata_mt_job_state ps; LIST_HEAD(works); - int nworks, nid = 0; + int nworks, nid; + static volatile int global_nid = 0; if (job->size == 0) return; @@ -516,12 +517,15 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) ps.chunk_size = max(ps.chunk_size, job->min_chunk); ps.chunk_size = roundup(ps.chunk_size, job->align); + nid = global_nid; list_for_each_entry(pw, &works, pw_list) - if (job->numa_aware) - queue_work_node((++nid % num_node_state(N_MEMORY)), - system_unbound_wq, &pw->pw_work); - else + if (job->numa_aware) { + queue_work_node(nid, system_unbound_wq, &pw->pw_work); + nid = next_node(nid, node_states[N_CPU]); + } else queue_work(system_unbound_wq, &pw->pw_work); + if (job->numa_aware) + global_nid = nid; /* Use the current thread, which saves starting a workqueue worker. */ padata_work_init(&my_work, padata_mt_helper, &ps, PADATA_WORK_ONSTACK); ``` >> >> if (job->size == 0) >> return; >> @@ -517,7 +517,11 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) >> ps.chunk_size = roundup(ps.chunk_size, job->align); >> >> list_for_each_entry(pw, &works, pw_list) >> - queue_work(system_unbound_wq, &pw->pw_work); >> + if (job->numa_aware) >> + queue_work_node((++nid % num_node_state(N_MEMORY)), >> + system_unbound_wq, &pw->pw_work); > > I think we should use nid = next_node(nid, node_states[N_CPU]) instead of > ++nid % num_node_state(N_MEMORY). You are picking the next node with CPU > to handle the job. > > Tim > I agree.
On Fri, 2024-01-12 at 15:09 +0800, Gang Li wrote: > On 2024/1/12 01:50, Tim Chen wrote: > > On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: > > > When a group of tasks that access different nodes are scheduled on the > > > same node, they may encounter bandwidth bottlenecks and access latency. > > > > > > Thus, numa_aware flag is introduced here, allowing tasks to be > > > distributed across different nodes to fully utilize the advantage of > > > multi-node systems. > > > > > > Signed-off-by: Gang Li <gang.li@linux.dev> > > > --- > > > include/linux/padata.h | 3 +++ > > > kernel/padata.c | 8 ++++++-- > > > mm/mm_init.c | 1 + > > > 3 files changed, 10 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/linux/padata.h b/include/linux/padata.h > > > index 495b16b6b4d72..f79ccd50e7f40 100644 > > > --- a/include/linux/padata.h > > > +++ b/include/linux/padata.h > > > @@ -137,6 +137,8 @@ struct padata_shell { > > > * appropriate for one worker thread to do at once. > > > * @max_threads: Max threads to use for the job, actual number may be less > > > * depending on task size and minimum chunk size. > > > + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but > > > + * no CPU, dispatch its jobs to a random CPU. > > > */ > > > struct padata_mt_job { > > > void (*thread_fn)(unsigned long start, unsigned long end, void *arg); > > > @@ -146,6 +148,7 @@ struct padata_mt_job { > > > unsigned long align; > > > unsigned long min_chunk; > > > int max_threads; > > > + bool numa_aware; > > > }; > > > > > > /** > > > diff --git a/kernel/padata.c b/kernel/padata.c > > > index 179fb1518070c..1c2b3a337479e 100644 > > > --- a/kernel/padata.c > > > +++ b/kernel/padata.c > > > @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) > > > struct padata_work my_work, *pw; > > > struct padata_mt_job_state ps; > > > LIST_HEAD(works); > > > - int nworks; > > > + int nworks, nid = 0; > > > > If we always start from 0, we may be biased towards the low numbered node, > > and not use high numbered nodes at all. Suggest you do > > static nid = 0; > > > > When we use `static`, if there are multiple parallel calls to > `padata_do_multithreaded`, it may result in an uneven distribution of > tasks for each padata_do_multithreaded. > > We can make the following modifications to address this issue. > > ``` > diff --git a/kernel/padata.c b/kernel/padata.c > index 1c2b3a337479e..925e48df6dd8d 100644 > --- a/kernel/padata.c > +++ b/kernel/padata.c > @@ -485,7 +485,8 @@ void __init padata_do_multithreaded(struct > padata_mt_job *job) > struct padata_work my_work, *pw; > struct padata_mt_job_state ps; > LIST_HEAD(works); > - int nworks, nid = 0; > + int nworks, nid; > + static volatile int global_nid = 0; > > if (job->size == 0) > return; > @@ -516,12 +517,15 @@ void __init padata_do_multithreaded(struct > padata_mt_job *job) > ps.chunk_size = max(ps.chunk_size, job->min_chunk); > ps.chunk_size = roundup(ps.chunk_size, job->align); > > + nid = global_nid; > list_for_each_entry(pw, &works, pw_list) > - if (job->numa_aware) > - queue_work_node((++nid % num_node_state(N_MEMORY)), > - system_unbound_wq, &pw->pw_work); > - else > + if (job->numa_aware) { > + queue_work_node(nid, system_unbound_wq, > &pw->pw_work); > + nid = next_node(nid, node_states[N_CPU]); > + } else > queue_work(system_unbound_wq, &pw->pw_work); > + if (job->numa_aware) > + global_nid = nid; Thinking more about it, there could still be multiple threads working at the same time with stale global_nid. We should probably do a compare exchange of global_nid with new nid only if the global nid was unchanged. Otherwise we should go to the next node with the changed global nid before we queue the job. Tim > > /* Use the current thread, which saves starting a workqueue > worker. */ > padata_work_init(&my_work, padata_mt_helper, &ps, > PADATA_WORK_ONSTACK); > ``` > > > > > > > > if (job->size == 0) > > > return; > > > @@ -517,7 +517,11 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) > > > ps.chunk_size = roundup(ps.chunk_size, job->align); > > > > > > list_for_each_entry(pw, &works, pw_list) > > > - queue_work(system_unbound_wq, &pw->pw_work); > > > + if (job->numa_aware) > > > + queue_work_node((++nid % num_node_state(N_MEMORY)), > > > + system_unbound_wq, &pw->pw_work); > > > > I think we should use nid = next_node(nid, node_states[N_CPU]) instead of > > ++nid % num_node_state(N_MEMORY). You are picking the next node with CPU > > to handle the job. > > > > Tim > > > > I agree.
On 2024/1/13 02:27, Tim Chen wrote: > On Fri, 2024-01-12 at 15:09 +0800, Gang Li wrote: >> On 2024/1/12 01:50, Tim Chen wrote: >>> On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: >>>> When a group of tasks that access different nodes are scheduled on the >>>> same node, they may encounter bandwidth bottlenecks and access latency. >>>> >>>> Thus, numa_aware flag is introduced here, allowing tasks to be >>>> distributed across different nodes to fully utilize the advantage of >>>> multi-node systems. >>>> >>>> Signed-off-by: Gang Li <gang.li@linux.dev> >>>> --- >>>> include/linux/padata.h | 3 +++ >>>> kernel/padata.c | 8 ++++++-- >>>> mm/mm_init.c | 1 + >>>> 3 files changed, 10 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/include/linux/padata.h b/include/linux/padata.h >>>> index 495b16b6b4d72..f79ccd50e7f40 100644 >>>> --- a/include/linux/padata.h >>>> +++ b/include/linux/padata.h >>>> @@ -137,6 +137,8 @@ struct padata_shell { >>>> * appropriate for one worker thread to do at once. >>>> * @max_threads: Max threads to use for the job, actual number may be less >>>> * depending on task size and minimum chunk size. >>>> + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but >>>> + * no CPU, dispatch its jobs to a random CPU. >>>> */ >>>> struct padata_mt_job { >>>> void (*thread_fn)(unsigned long start, unsigned long end, void *arg); >>>> @@ -146,6 +148,7 @@ struct padata_mt_job { >>>> unsigned long align; >>>> unsigned long min_chunk; >>>> int max_threads; >>>> + bool numa_aware; >>>> }; >>>> >>>> /** >>>> diff --git a/kernel/padata.c b/kernel/padata.c >>>> index 179fb1518070c..1c2b3a337479e 100644 >>>> --- a/kernel/padata.c >>>> +++ b/kernel/padata.c >>>> @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) >>>> struct padata_work my_work, *pw; >>>> struct padata_mt_job_state ps; >>>> LIST_HEAD(works); >>>> - int nworks; >>>> + int nworks, nid = 0; >>> >>> If we always start from 0, we may be biased towards the low numbered node, >>> and not use high numbered nodes at all. Suggest you do >>> static nid = 0; >>> >> >> When we use `static`, if there are multiple parallel calls to >> `padata_do_multithreaded`, it may result in an uneven distribution of >> tasks for each padata_do_multithreaded. >> >> We can make the following modifications to address this issue. >> >> ``` >> diff --git a/kernel/padata.c b/kernel/padata.c >> index 1c2b3a337479e..925e48df6dd8d 100644 >> --- a/kernel/padata.c >> +++ b/kernel/padata.c >> @@ -485,7 +485,8 @@ void __init padata_do_multithreaded(struct >> padata_mt_job *job) >> struct padata_work my_work, *pw; >> struct padata_mt_job_state ps; >> LIST_HEAD(works); >> - int nworks, nid = 0; >> + int nworks, nid; >> + static volatile int global_nid = 0; >> >> if (job->size == 0) >> return; >> @@ -516,12 +517,15 @@ void __init padata_do_multithreaded(struct >> padata_mt_job *job) >> ps.chunk_size = max(ps.chunk_size, job->min_chunk); >> ps.chunk_size = roundup(ps.chunk_size, job->align); >> >> + nid = global_nid; >> list_for_each_entry(pw, &works, pw_list) >> - if (job->numa_aware) >> - queue_work_node((++nid % num_node_state(N_MEMORY)), >> - system_unbound_wq, &pw->pw_work); >> - else >> + if (job->numa_aware) { >> + queue_work_node(nid, system_unbound_wq, >> &pw->pw_work); >> + nid = next_node(nid, node_states[N_CPU]); >> + } else >> queue_work(system_unbound_wq, &pw->pw_work); >> + if (job->numa_aware) >> + global_nid = nid; > > Thinking more about it, there could still be multiple threads working > at the same time with stale global_nid. We should probably do a compare > exchange of global_nid with new nid only if the global nid was unchanged. > Otherwise we should go to the next node with the changed global nid before > we queue the job. > > Tim > How about: ``` nid = global_nid; list_for_each_entry(pw, &works, pw_list) if (job->numa_aware) { int old_node = nid; queue_work_node(nid, system_unbound_wq, &pw->pw_work); nid = next_node(nid, node_states[N_CPU]); cmpxchg(&global_nid, old_node, nid); } else queue_work(system_unbound_wq, &pw->pw_work); ```
On Mon, 2024-01-15 at 16:57 +0800, Gang Li wrote: > > On 2024/1/13 02:27, Tim Chen wrote: > > On Fri, 2024-01-12 at 15:09 +0800, Gang Li wrote: > > > On 2024/1/12 01:50, Tim Chen wrote: > > > > On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: > > > > > When a group of tasks that access different nodes are scheduled on the > > > > > same node, they may encounter bandwidth bottlenecks and access latency. > > > > > > > > > > Thus, numa_aware flag is introduced here, allowing tasks to be > > > > > distributed across different nodes to fully utilize the advantage of > > > > > multi-node systems. > > > > > > > > > > Signed-off-by: Gang Li <gang.li@linux.dev> > > > > > --- > > > > > include/linux/padata.h | 3 +++ > > > > > kernel/padata.c | 8 ++++++-- > > > > > mm/mm_init.c | 1 + > > > > > 3 files changed, 10 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/include/linux/padata.h b/include/linux/padata.h > > > > > index 495b16b6b4d72..f79ccd50e7f40 100644 > > > > > --- a/include/linux/padata.h > > > > > +++ b/include/linux/padata.h > > > > > @@ -137,6 +137,8 @@ struct padata_shell { > > > > > * appropriate for one worker thread to do at once. > > > > > * @max_threads: Max threads to use for the job, actual number may be less > > > > > * depending on task size and minimum chunk size. > > > > > + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but > > > > > + * no CPU, dispatch its jobs to a random CPU. > > > > > */ > > > > > struct padata_mt_job { > > > > > void (*thread_fn)(unsigned long start, unsigned long end, void *arg); > > > > > @@ -146,6 +148,7 @@ struct padata_mt_job { > > > > > unsigned long align; > > > > > unsigned long min_chunk; > > > > > int max_threads; > > > > > + bool numa_aware; > > > > > }; > > > > > > > > > > /** > > > > > diff --git a/kernel/padata.c b/kernel/padata.c > > > > > index 179fb1518070c..1c2b3a337479e 100644 > > > > > --- a/kernel/padata.c > > > > > +++ b/kernel/padata.c > > > > > @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) > > > > > struct padata_work my_work, *pw; > > > > > struct padata_mt_job_state ps; > > > > > LIST_HEAD(works); > > > > > - int nworks; > > > > > + int nworks, nid = 0; > > > > > > > > If we always start from 0, we may be biased towards the low numbered node, > > > > and not use high numbered nodes at all. Suggest you do > > > > static nid = 0; > > > > > > > > > > When we use `static`, if there are multiple parallel calls to > > > `padata_do_multithreaded`, it may result in an uneven distribution of > > > tasks for each padata_do_multithreaded. > > > > > > We can make the following modifications to address this issue. > > > > > > ``` > > > diff --git a/kernel/padata.c b/kernel/padata.c > > > index 1c2b3a337479e..925e48df6dd8d 100644 > > > --- a/kernel/padata.c > > > +++ b/kernel/padata.c > > > @@ -485,7 +485,8 @@ void __init padata_do_multithreaded(struct > > > padata_mt_job *job) > > > struct padata_work my_work, *pw; > > > struct padata_mt_job_state ps; > > > LIST_HEAD(works); > > > - int nworks, nid = 0; > > > + int nworks, nid; > > > + static volatile int global_nid = 0; > > > > > > if (job->size == 0) > > > return; > > > @@ -516,12 +517,15 @@ void __init padata_do_multithreaded(struct > > > padata_mt_job *job) > > > ps.chunk_size = max(ps.chunk_size, job->min_chunk); > > > ps.chunk_size = roundup(ps.chunk_size, job->align); > > > > > > + nid = global_nid; > > > list_for_each_entry(pw, &works, pw_list) > > > - if (job->numa_aware) > > > - queue_work_node((++nid % num_node_state(N_MEMORY)), > > > - system_unbound_wq, &pw->pw_work); > > > - else > > > + if (job->numa_aware) { > > > + queue_work_node(nid, system_unbound_wq, > > > &pw->pw_work); > > > + nid = next_node(nid, node_states[N_CPU]); > > > + } else > > > queue_work(system_unbound_wq, &pw->pw_work); > > > + if (job->numa_aware) > > > + global_nid = nid; > > > > Thinking more about it, there could still be multiple threads working > > at the same time with stale global_nid. We should probably do a compare > > exchange of global_nid with new nid only if the global nid was unchanged. > > Otherwise we should go to the next node with the changed global nid before > > we queue the job. > > > > Tim > > > How about: > ``` > nid = global_nid; > list_for_each_entry(pw, &works, pw_list) > if (job->numa_aware) { > int old_node = nid; > queue_work_node(nid, system_unbound_wq, &pw->pw_work); > nid = next_node(nid, node_states[N_CPU]); > cmpxchg(&global_nid, old_node, nid); > } else > queue_work(system_unbound_wq, &pw->pw_work); > > ``` > I am thinking something like static volatile atomic_t last_used_nid; list_for_each_entry(pw, &works, pw_list) if (job->numa_aware) { int old_node = atomic_read(&last_used_nid); do { nid = next_node_in(old_node, node_states[N_CPU]); } while (!atomic_try_cmpxchg(&last_used_nid, &old_node, nid)); queue_work_node(nid, system_unbound_wq, &pw->pw_work); } else { queue_work(system_unbound_wq, &pw->pw_work); } Note that we need to use next_node_in so we'll wrap around the node mask. Tim
Hi Tim, On 2024/1/18 06:14, Tim Chen wrote: > On Mon, 2024-01-15 at 16:57 +0800, Gang Li wrote: >> How about: >> ``` >> nid = global_nid; >> list_for_each_entry(pw, &works, pw_list) >> if (job->numa_aware) { >> int old_node = nid; >> queue_work_node(nid, system_unbound_wq, &pw->pw_work); >> nid = next_node(nid, node_states[N_CPU]); >> cmpxchg(&global_nid, old_node, nid); >> } else >> queue_work(system_unbound_wq, &pw->pw_work); >> >> ``` >> My original idea was to have all tasks from a single padata_do_multithreaded distributed continuously across NUMA nodes. In that case, the task distribution would be predictable for a single padata_do_multithreaded call. > > I am thinking something like > > static volatile atomic_t last_used_nid; > > list_for_each_entry(pw, &works, pw_list) > if (job->numa_aware) { > int old_node = atomic_read(&last_used_nid); > > do { > nid = next_node_in(old_node, node_states[N_CPU]); > } while (!atomic_try_cmpxchg(&last_used_nid, &old_node, nid)); However, having the tasks from all parallel padata_do_multithreaded globally distributed across NUMA nodes is also fine by me. I don't have a strong preference. > queue_work_node(nid, system_unbound_wq, &pw->pw_work); > } else { > queue_work(system_unbound_wq, &pw->pw_work); > } > > Note that we need to use next_node_in so we'll wrap around the node mask. >
diff --git a/include/linux/padata.h b/include/linux/padata.h index 495b16b6b4d72..f79ccd50e7f40 100644 --- a/include/linux/padata.h +++ b/include/linux/padata.h @@ -137,6 +137,8 @@ struct padata_shell { * appropriate for one worker thread to do at once. * @max_threads: Max threads to use for the job, actual number may be less * depending on task size and minimum chunk size. + * @numa_aware: Dispatch jobs to different nodes. If a node only has memory but + * no CPU, dispatch its jobs to a random CPU. */ struct padata_mt_job { void (*thread_fn)(unsigned long start, unsigned long end, void *arg); @@ -146,6 +148,7 @@ struct padata_mt_job { unsigned long align; unsigned long min_chunk; int max_threads; + bool numa_aware; }; /** diff --git a/kernel/padata.c b/kernel/padata.c index 179fb1518070c..1c2b3a337479e 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -485,7 +485,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) struct padata_work my_work, *pw; struct padata_mt_job_state ps; LIST_HEAD(works); - int nworks; + int nworks, nid = 0; if (job->size == 0) return; @@ -517,7 +517,11 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) ps.chunk_size = roundup(ps.chunk_size, job->align); list_for_each_entry(pw, &works, pw_list) - queue_work(system_unbound_wq, &pw->pw_work); + if (job->numa_aware) + queue_work_node((++nid % num_node_state(N_MEMORY)), + system_unbound_wq, &pw->pw_work); + else + queue_work(system_unbound_wq, &pw->pw_work); /* Use the current thread, which saves starting a workqueue worker. */ padata_work_init(&my_work, padata_mt_helper, &ps, PADATA_WORK_ONSTACK); diff --git a/mm/mm_init.c b/mm/mm_init.c index 89dc29f1e6c6f..59fcffddf65a3 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -2225,6 +2225,7 @@ static int __init deferred_init_memmap(void *data) .align = PAGES_PER_SECTION, .min_chunk = PAGES_PER_SECTION, .max_threads = max_threads, + .numa_aware = false, }; padata_do_multithreaded(&job);