public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Donglin Peng <dolinux.peng@gmail.com>, ast@kernel.org
Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	Andrii Nakryiko	 <andrii.nakryiko@gmail.com>,
	Alan Maguire <alan.maguire@oracle.com>,
	Song Liu	 <song@kernel.org>, pengdonglin <pengdonglin@xiaomi.com>
Subject: Re: [RFC PATCH v4 4/7] libbpf: Implement lazy sorting validation for binary search optimization
Date: Tue, 04 Nov 2025 16:29:21 -0800	[thread overview]
Message-ID: <123fde84e56aaa2dcccc16a2eac00d0e28a0823e.camel@gmail.com> (raw)
In-Reply-To: <20251104134033.344807-5-dolinux.peng@gmail.com>

On Tue, 2025-11-04 at 21:40 +0800, Donglin Peng wrote:
> From: pengdonglin <pengdonglin@xiaomi.com>
> 
> This patch adds lazy validation of BTF type ordering to determine if types
> are sorted by name. The check is performed on first access and cached,
> enabling efficient binary search for sorted BTF while maintaining linear
> search fallback for unsorted cases.
> 
> Cc: Eduard Zingerman <eddyz87@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Cc: Alan Maguire <alan.maguire@oracle.com>
> Cc: Song Liu <song@kernel.org>
> Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
> Signed-off-by: Donglin Peng <dolinux.peng@gmail.com>
> ---
>  tools/lib/bpf/btf.c | 76 +++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 74 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index 5af14304409c..0ee00cec5c05 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -26,6 +26,10 @@
>  
>  #define BTF_MAX_NR_TYPES 0x7fffffffU
>  #define BTF_MAX_STR_OFFSET 0x7fffffffU
> +/* sort verification occurs lazily upon first btf_find_type_by_name_kind()
> + * call
> + */
> +#define BTF_NEED_SORT_CHECK ((__u32)-1)
>  
>  static struct btf_type btf_void;
>  
> @@ -96,6 +100,10 @@ struct btf {
>  	 *   - doesn't include special [0] void type;
>  	 *   - for split BTF counts number of sorted and named types added on
>  	 *     top of base BTF.
> +	 *   - BTF_NEED_SORT_CHECK value indicates sort validation will be performed
> +	 *     on first call to btf_find_type_by_name_kind.
> +	 *   - zero value indicates applied sorting check with unsorted BTF or no
> +	 *     named types.

And this can be another flag.

>  	 */
>  	__u32 nr_sorted_types;
>  	/* if not NULL, points to the base BTF on top of which the current
> @@ -903,8 +911,67 @@ int btf__resolve_type(const struct btf *btf, __u32 type_id)
>  	return type_id;
>  }
>  
> -/*
> - * Find BTF types with matching names within the [left, right] index range.
> +static int btf_compare_type_names(const void *a, const void *b, void *priv)
> +{
> +	struct btf *btf = (struct btf *)priv;
> +	struct btf_type *ta = btf_type_by_id(btf, *(__u32 *)a);
> +	struct btf_type *tb = btf_type_by_id(btf, *(__u32 *)b);
> +	const char *na, *nb;
> +	bool anon_a, anon_b;
> +
> +	na = btf__str_by_offset(btf, ta->name_off);
> +	nb = btf__str_by_offset(btf, tb->name_off);
> +	anon_a = str_is_empty(na);
> +	anon_b = str_is_empty(nb);
> +
> +	if (anon_a && !anon_b)
> +		return 1;
> +	if (!anon_a && anon_b)
> +		return -1;
> +	if (anon_a && anon_b)
> +		return 0;
> +
> +	return strcmp(na, nb);
> +}
> +
> +/* Verifies BTF type ordering by name and counts named types.
> + *
> + * Checks that types are sorted in ascending order with named types
> + * before anonymous ones. If verified, sets nr_sorted_types to the
> + * number of named types.
> + */
> +static void btf_check_sorted(struct btf *btf, int start_id)
> +{
> +	const struct btf_type *t;
> +	int i, n, nr_sorted_types;
> +
> +	if (likely(btf->nr_sorted_types != BTF_NEED_SORT_CHECK))
> +		return;
> +	btf->nr_sorted_types = 0;
> +
> +	if (btf->nr_types < 2)
> +		return;
> +
> +	nr_sorted_types = 0;
> +	n = btf__type_cnt(btf);
> +	for (n--, i = start_id; i < n; i++) {
             ^^^
     why not -1 one line before?

> +		int k = i + 1;
> +
> +		if (btf_compare_type_names(&i, &k, btf) > 0)
> +			return;
> +		t = btf_type_by_id(btf, k);
> +		if (!str_is_empty(btf__str_by_offset(btf, t->name_off)))
> +			nr_sorted_types++;
> +	}
> +
> +	t = btf_type_by_id(btf, start_id);
> +	if (!str_is_empty(btf__str_by_offset(btf, t->name_off)))
> +		nr_sorted_types++;
> +	if (nr_sorted_types)
> +		btf->nr_sorted_types = nr_sorted_types;

I think that maintaining nr_sorted_types only for named types is an
unnecessary complication. Binary search will skip those anyway,
probably in one iteration.

> +}
> +
> +/* Find BTF types with matching names within the [left, right] index range.
>   * On success, updates *left and *right to the boundaries of the matching range
>   * and returns the leftmost matching index.
>   */
> @@ -978,6 +1045,8 @@ static __s32 btf_find_type_by_name_kind(const struct btf *btf, int start_id,
>  	}
>  
>  	if (err == -ENOENT) {
> +		btf_check_sorted((struct btf *)btf, btf->start_id);
> +
>  		if (btf->nr_sorted_types) {
>  			/* binary search */
>  			__s32 l, r;
> @@ -1102,6 +1171,7 @@ static struct btf *btf_new_empty(struct btf *base_btf)
>  	btf->fd = -1;
>  	btf->ptr_sz = sizeof(void *);
>  	btf->swapped_endian = false;
> +	btf->nr_sorted_types = BTF_NEED_SORT_CHECK;
>  
>  	if (base_btf) {
>  		btf->base_btf = base_btf;
> @@ -1153,6 +1223,7 @@ static struct btf *btf_new(const void *data, __u32 size, struct btf *base_btf, b
>  	btf->start_id = 1;
>  	btf->start_str_off = 0;
>  	btf->fd = -1;
> +	btf->nr_sorted_types = BTF_NEED_SORT_CHECK;
>  
>  	if (base_btf) {
>  		btf->base_btf = base_btf;
> @@ -1811,6 +1882,7 @@ static void btf_invalidate_raw_data(struct btf *btf)
>  		free(btf->raw_data_swapped);
>  		btf->raw_data_swapped = NULL;
>  	}
> +	btf->nr_sorted_types = BTF_NEED_SORT_CHECK;
>  }
>  
>  /* Ensure BTF is ready to be modified (by splitting into a three memory

  reply	other threads:[~2025-11-05  0:29 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04 13:40 [RFC PATCH v4 0/7] libbpf: BTF performance optimizations with permutation and binary search Donglin Peng
2025-11-04 13:40 ` [RFC PATCH v4 1/7] libbpf: Extract BTF type remapping logic into helper function Donglin Peng
2025-11-04 23:16   ` Eduard Zingerman
2025-11-05  0:11   ` Andrii Nakryiko
2025-11-05  0:36     ` Eduard Zingerman
2025-11-05  0:57       ` Andrii Nakryiko
2025-11-05  1:23         ` Eduard Zingerman
2025-11-05 18:20           ` Andrii Nakryiko
2025-11-05 19:41             ` Eduard Zingerman
2025-11-06 17:09               ` Andrii Nakryiko
2025-11-04 13:40 ` [RFC PATCH v4 2/7] libbpf: Add BTF permutation support for type reordering Donglin Peng
2025-11-04 23:45   ` Eduard Zingerman
2025-11-05 11:31     ` Donglin Peng
2025-11-05  0:11   ` Andrii Nakryiko
2025-11-05  0:16     ` Eduard Zingerman
2025-11-05  1:04       ` Andrii Nakryiko
2025-11-05  1:20         ` Eduard Zingerman
2025-11-05 13:19           ` Donglin Peng
2025-11-05 18:32             ` Andrii Nakryiko
2025-11-05 18:23           ` Andrii Nakryiko
2025-11-05 19:23             ` Eduard Zingerman
2025-11-06 17:21               ` Andrii Nakryiko
2025-11-07  2:36             ` Donglin Peng
2025-11-07 17:43               ` Andrii Nakryiko
2025-11-05 12:52     ` Donglin Peng
2025-11-05 18:29       ` Andrii Nakryiko
2025-11-06  7:31         ` Donglin Peng
2025-11-06 17:12           ` Andrii Nakryiko
2025-11-07  1:39             ` Donglin Peng
2025-11-04 13:40 ` [RFC PATCH v4 3/7] libbpf: Optimize type lookup with binary search for sorted BTF Donglin Peng
2025-11-04 14:15   ` bot+bpf-ci
2025-11-05  0:06   ` Eduard Zingerman
2025-11-05  0:11   ` Andrii Nakryiko
2025-11-05  0:19     ` Eduard Zingerman
2025-11-05  0:54       ` Andrii Nakryiko
2025-11-05  1:17         ` Eduard Zingerman
2025-11-05 13:48           ` Donglin Peng
2025-11-05 16:52             ` Eduard Zingerman
2025-11-06  6:10               ` Donglin Peng
2025-11-05 18:11             ` Andrii Nakryiko
2025-11-06  7:49               ` Donglin Peng
2025-11-06 17:31                 ` Andrii Nakryiko
2025-11-07  4:57                   ` Donglin Peng
2025-11-07 17:01                     ` Andrii Nakryiko
2025-11-10  2:04                       ` Donglin Peng
2025-11-04 13:40 ` [RFC PATCH v4 4/7] libbpf: Implement lazy sorting validation for binary search optimization Donglin Peng
2025-11-05  0:29   ` Eduard Zingerman [this message]
2025-11-04 13:40 ` [RFC PATCH v4 5/7] btf: Optimize type lookup with binary search Donglin Peng
2025-11-04 17:14   ` Alexei Starovoitov
2025-11-05 13:22     ` Donglin Peng
2025-11-04 13:40 ` [RFC PATCH v4 6/7] btf: Add lazy sorting validation for " Donglin Peng
2025-11-04 13:40 ` [RFC PATCH v4 7/7] selftests/bpf: Add test cases for btf__permute functionality Donglin Peng
2025-11-05  0:41   ` Eduard Zingerman

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=123fde84e56aaa2dcccc16a2eac00d0e28a0823e.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dolinux.peng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pengdonglin@xiaomi.com \
    --cc=song@kernel.org \
    /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