From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Cc: bpf@vger.kernel.org, Eduard Zingerman <eddyz87@gmail.com>,
Tejun Heo <tj@kernel.org>,
xavier_qy@163.com, longman@redhat.com, lizefan.x@bytedance.com,
hannes@cmpxchg.org, mkoutny@suse.com, akpm@linux-foundation.org,
jserv@ccns.ncku.edu.tw, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: Using union-find in BPF verifier (was: Enhance union-find with KUnit tests and optimization improvements)
Date: Sat, 19 Oct 2024 08:07:45 +0800 [thread overview]
Message-ID: <ZxL4UTGzV1yd07jd@visitorckw-System-Product-Name> (raw)
In-Reply-To: <aci6pn57bqjfcshbak7ekxb7zr5zz72u3rxyu4zbp5w3mvljx2@b4rn2e4rb4rl>
On Thu, Oct 17, 2024 at 03:10:50PM +0800, Shung-Hsi Yu wrote:
> Michal mentioned lib/union_find.c during a discussion. I think we may
> have a use for in BPF verifier (kernel/bpf/verifier.c) that could
> further simplify the code. Eduard (who wrote the code shown below)
> probably would have a better idea.
>
> On Mon, Oct 07, 2024 at 06:19:10AM GMT, Tejun Heo wrote:
> > On Mon, Oct 07, 2024 at 11:28:27PM +0800, Kuan-Wei Chiu wrote:
> > > This patch series adds KUnit tests for the union-find implementation
> > > and optimizes the path compression in the uf_find() function to achieve
> > > a lower tree height and improved efficiency. Additionally, it modifies
> > > uf_union() to return a boolean value indicating whether a merge
> > > occurred, enhancing the process of calculating the number of groups in
> > > the cgroup cpuset.
> >
> > I'm not necessarily against the patchset but this probably is becoming too
> > much polishing for something which is only used by cpuset in a pretty cold
> > path. It probably would be a good idea to concentrate on finding more use
> > cases.
>
> In BPF verifier we do the following to identify the outermost loop in a
> BPF program.
>
> static struct bpf_verifier_state *get_loop_entry(struct bpf_verifier_state *st)
> {
> struct bpf_verifier_state *topmost = st->loop_entry, *old;
>
> while (topmost && topmost->loop_entry && topmost != topmost->loop_entry)
> topmost = topmost->loop_entry;
>
> while (st && st->loop_entry != topmost) {
> old = st->loop_entry;
> st->loop_entry = topmost;
> st = old;
> }
> return topmost;
> }
>
> static void update_loop_entry(struct bpf_verifier_state *cur, struct bpf_verifier_state *hdr)
> {
> struct bpf_verifier_state *cur1, *hdr1;
>
> cur1 = get_loop_entry(cur) ?: cur;
> hdr1 = get_loop_entry(hdr) ?: hdr;
>
> if (hdr1->branches && hdr1->dfs_depth <= cur1->dfs_depth) {
> cur->loop_entry = hdr;
> hdr->used_as_loop_entry = true;
> }
> }
>
> Squinting a bit get_loop_entry() looks quite like uf_find() and
> update_loop_entry() looks quite link uf_union(). So perhaps we could get
> a straight-forward conversion here.
>
From a quick glance, it seems that there are still some differences
between update_loop_entry() and uf_union(). If we want to use
lib/union_find.c, we would need a new union function to ensure the
merge order, i.e., ensuring that a.parent = b but not b.parent = a.
Additionally, used_as_loop_entry can be replaced with
uf_find(a) == a && a->rank != 1.
However, I'm not entirely sure if this would make the code easier to
understand compared to the current implementation.
Regards,
Kuan-Wei
next prev parent reply other threads:[~2024-10-19 0:07 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
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 [this message]
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=ZxL4UTGzV1yd07jd@visitorckw-System-Product-Name \
--to=visitorckw@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=eddyz87@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=longman@redhat.com \
--cc=mkoutny@suse.com \
--cc=shung-hsi.yu@suse.com \
--cc=tj@kernel.org \
--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