From: Waiman Long <llong@redhat.com>
To: Kuan-Wei Chiu <visitorckw@gmail.com>,
xavier_qy@163.com, lizefan.x@bytedance.com, tj@kernel.org,
hannes@cmpxchg.org, mkoutny@suse.com, akpm@linux-foundation.org
Cc: jserv@ccns.ncku.edu.tw, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [PATCH v2 5/6] cgroup/cpuset: Optimize domain counting using updated uf_union()
Date: Tue, 8 Oct 2024 10:02:23 -0400 [thread overview]
Message-ID: <ef7f2495-06fc-4409-8233-062d2e884271@redhat.com> (raw)
In-Reply-To: <20241007152833.2282199-6-visitorckw@gmail.com>
On 10/7/24 11:28 AM, Kuan-Wei Chiu wrote:
> Improve the efficiency of calculating the total number of scheduling
> domains by using the updated uf_union function, which now returns a
> boolean to indicate if a merge occurred. Previously, an additional loop
> was needed to count root nodes for distinct groups. With this change,
> each successful merge reduces the domain count (ndoms) directly,
> eliminating the need for the final loop and enhancing performance.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Note: Tested with test_cpuset_prs.sh
>
> Side note: I know this optimization provides limited efficiency
> improvements in this case, but since the union-find code is in the
> library and other users may need group counting in the future, and
> the required code change is minimal, I think it's still worthwhile.
>
> kernel/cgroup/cpuset.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index a4dd285cdf39..5e9301550d43 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -817,6 +817,8 @@ static int generate_sched_domains(cpumask_var_t **domains,
> if (root_load_balance && (csn == 1))
> goto single_root_domain;
>
> + ndoms = csn;
> +
> for (i = 0; i < csn; i++)
> uf_node_init(&csa[i]->node);
>
> @@ -829,17 +831,11 @@ static int generate_sched_domains(cpumask_var_t **domains,
> * partition root cpusets.
> */
> WARN_ON_ONCE(cgrpv2);
> - uf_union(&csa[i]->node, &csa[j]->node);
> + ndoms -= uf_union(&csa[i]->node, &csa[j]->node);
You are taking the implicit assumption that a boolean true is casted to
int 1. That is the usual practice, but it is not part of the C standard
itself though it is for C++. I will be more comfortable with the "if
(cond) ndoms++" form. It will also be more clear.
Cheers,
Longman
next prev parent reply other threads:[~2024-10-08 14:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 15:28 [PATCH v2 0/6] Enhance union-find with KUnit tests and optimization improvements Kuan-Wei Chiu
2024-10-07 15:28 ` [PATCH v2 1/6] lib/union_find: Add EXPORT_SYMBOL() for uf_find() and uf_union() Kuan-Wei Chiu
2024-10-09 14:55 ` Waiman Long
2024-10-07 15:28 ` [PATCH v2 2/6] lib/union_find: Change uf_union() return type to bool Kuan-Wei Chiu
2024-10-07 15:28 ` [PATCH v2 3/6] lib: Add KUnit tests for union-find implementation Kuan-Wei Chiu
2024-10-07 15:28 ` [PATCH v2 4/6] lib/union_find: Optimize uf_find() with enhanced path compression Kuan-Wei Chiu
2024-10-07 15:28 ` [PATCH v2 5/6] cgroup/cpuset: Optimize domain counting using updated uf_union() Kuan-Wei Chiu
2024-10-08 14:02 ` Waiman Long [this message]
2024-10-08 16:45 ` Kuan-Wei Chiu
2024-10-08 20:00 ` Waiman Long
2024-10-07 15:28 ` [PATCH v2 6/6] MAINTAINERS: Add Kuan-Wei as co-maintainer for union-find Kuan-Wei Chiu
2024-10-07 16:19 ` [PATCH v2 0/6] Enhance union-find with KUnit tests and optimization improvements Tejun Heo
2024-10-08 6:19 ` Kuan-Wei Chiu
2024-10-17 7:10 ` Using union-find in BPF verifier (was: Enhance union-find with KUnit tests and optimization improvements) Shung-Hsi Yu
2024-10-17 8:08 ` Eduard Zingerman
2024-10-21 17:14 ` Alexei Starovoitov
2024-10-19 0:07 ` Kuan-Wei Chiu
2024-10-09 9:09 ` [PATCH v2 0/6] Enhance union-find with KUnit tests and optimization improvements Christoph Hellwig
2024-10-09 11:15 ` Kuan-Wei Chiu
2024-10-09 14:13 ` Kuan-Wei Chiu
2024-10-09 14:53 ` Waiman Long
2024-10-09 16:41 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef7f2495-06fc-4409-8233-062d2e884271@redhat.com \
--to=llong@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
--cc=visitorckw@gmail.com \
--cc=xavier_qy@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®