Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1810193rdd; Thu, 11 Jan 2024 09:50:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IF/jGzzoloTjpDVmB3brWNHPC8q0UN/U2382ndjITjQF6PqHZkQp5BhwrRwPcaDyldiudP8 X-Received: by 2002:a05:6359:1c11:b0:175:78e6:ff50 with SMTP id us17-20020a0563591c1100b0017578e6ff50mr135265rwb.14.1704995435760; Thu, 11 Jan 2024 09:50:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704995435; cv=none; d=google.com; s=arc-20160816; b=VL/HIt5zg/mZHJcbTtqM/L1+860//n5pT5pnAsQ1+0Yg+QB3ncZP9exn1RpYP+pPou RxfpEWC1GTg9WWUk+qyk7SFkU/jbv25OnHwwkSFgRYPeDGWZUFXDEZJQxj4YahrIJsKi YvQgeNunMlE1yom64ygHJdQEkZ82X183QIN8KNCbjwqoryicNWocAK1ySZ3zVHDxvzLn Pyg4liPp36qZP6S+L9uriyh65QiPBYrlJtfdCWkGg9dIILvxis0Rd+me9yae/0LhqKqv kj0/+pVyY3veceNpjEZHBTQ576i4ZCJf6rJa0w7yhxoOPE63tyIOYu7c2AmrCtQr7DkG TxmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:content-transfer-encoding:references:in-reply-to:date:cc :to:from:subject:message-id:dkim-signature; bh=YYFiuBV+WfNQ3+efG8A1C1r5CSguDr1GI7wEbWgHwNg=; fh=gDpnSSgvNOZ9o35uhFgrNUNXhEbmk0tXqswjx5BoEs4=; b=qFEJ/SeUbisqP2/TEGC3Kw9yCInI5M8PKEFN53iANKeleHCfTSm3lXGcelX90VPaMz 2DkQCM1bLTkUtW21hHGsRTE2zcZXz8JtcVL1l+1zAjG2pY9bjL41V8+rwREiEXuGj9Qj ipMiDhAK1JV+NWT+SyGL2lQg3bqbIBsYt5gWXnPtuRpsPCbLXkKgcbjH9bMPXkefMvMx tZeyuNcjHEVAub8F4g8pzx2i3MrTu64+7OLpF74HyW6nUc/l2p5vsOJW/4fCqi+W6hnu guBoUltdAj2rPFTlVRbYat1vOZhOHtP92OjHDFRJkAaTWd4DOFab1yvEvF4fzUbPzlHS 6i4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cuYCn8OR; spf=pass (google.com: domain of linux-kernel+bounces-23948-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23948-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id b12-20020a65668c000000b005ce007d628asi1517829pgw.133.2024.01.11.09.50.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 09:50:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23948-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cuYCn8OR; spf=pass (google.com: domain of linux-kernel+bounces-23948-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23948-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id E176C286C48 for ; Thu, 11 Jan 2024 17:50:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BA7A552F77; Thu, 11 Jan 2024 17:50:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cuYCn8OR" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 9C8AC3A1BE for ; Thu, 11 Jan 2024 17:50:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704995423; x=1736531423; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=k37B20/6MiGVylaiB+EuK9zFx7XSlnopblGDxK8CxTQ=; b=cuYCn8ORz0b0fEgyyZ6pAMqAcpc9glbVoC/OtGihn8anvfQgwch3RIQN 3V7Ll/SPnmm43GJEaMwerkC8tjmct8iz0hBdLUyczEIEiwUdMH5hmdudp aqivxl1O6EQSdhNh3wmWOsfMzcyAbpBSopsK+4loNC4XH7z04yKjGR9z/ PN33wPfLPI5X1CqL/kS50MCBIPTr0lR8Sj8bHoQNDBhP3D2RIPF8+7b02 8ZFlUwqRQ2k5ixhtBe4oyoxH+d26jR9i/b/9CGWCQz5UUl76rpQ/7Oa/B Q/0/O/vQOrp/4FFrT3izvewxkBzwuJosd4Y0P7e1GY4YJSpeley7uqU56 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10950"; a="5658678" X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="5658678" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 09:50:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="24710421" Received: from ldrake1-mobl3.amr.corp.intel.com (HELO [10.212.168.169]) ([10.212.168.169]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 09:50:21 -0800 Message-ID: <1d9074955618ea0b4b155701f7c1b8b18a43fa8d.camel@linux.intel.com> Subject: Re: [PATCH v3 3/7] padata: dispatch works on different nodes From: Tim Chen To: Gang Li , David Hildenbrand , David Rientjes , Mike Kravetz , Muchun Song , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, ligang.bdlg@bytedance.com Date: Thu, 11 Jan 2024 09:50:20 -0800 In-Reply-To: <20240102131249.76622-4-gang.li@linux.dev> References: <20240102131249.76622-1-gang.li@linux.dev> <20240102131249.76622-4-gang.li@linux.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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. >=20 > Thus, numa_aware flag is introduced here, allowing tasks to be > distributed across different nodes to fully utilize the advantage of > multi-node systems. >=20 > Signed-off-by: Gang Li > --- > include/linux/padata.h | 3 +++ > kernel/padata.c | 8 ++++++-- > mm/mm_init.c | 1 + > 3 files changed, 10 insertions(+), 2 deletions(-) >=20 > 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 le= ss > * depending on task size and minimum chunk size. > + * @numa_aware: Dispatch jobs to different nodes. If a node only has mem= ory 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; > }; > =20 > /** > 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 =3D 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 =3D 0; =20 > =20 > if (job->size =3D=3D 0) > return; > @@ -517,7 +517,11 @@ void __init padata_do_multithreaded(struct padata_mt= _job *job) > ps.chunk_size =3D roundup(ps.chunk_size, job->align); > =20 > 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 =3D 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); > =20 > /* 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 =3D PAGES_PER_SECTION, > .min_chunk =3D PAGES_PER_SECTION, > .max_threads =3D max_threads, > + .numa_aware =3D false, > }; > =20 > padata_do_multithreaded(&job);