> I feel u16 offset isn't really viable. Sooner or later we'd need to bump it,
> and then we will have a mix of u32 and u16 offsets.
We’re already using 22% of the addressable capacity of a u16.
It won’t get any better when introducing more locations.
> The main question I have is why funcsec size is bigger for (1) ?
> struct fn_info { u32 type_id, offset, params_offset; };
>
> this is fixed size record and the number of them should be the same
> as in (2) and (3), so single u32 params_offset should be smaller
> than u16[arg_cnt], assuming that on average arg_cnt >= 2.
>
> Or you meant that average arg_cnt <= 1,
> but then the math is suspicious, since struct fn_info should
> be 4-byte aligned as everything in BTF.
Average arg_cnt is 1.277, which is why (2) with u16 is smaller.
I did not know about the required 4-byte alignment of the BTF!
> Also for (3), if locs are inlined, why "Locations Size" is not zero ?
> Or the math for (3) is actually:
> struct fn_info { u32 type_id, offset } * num_of_funcs ?
Sorry for the confusion, I kept the numbers separated, but the locations are
indeed inside the funcsec table.
Updated table with (2-u16) and (3) aligned to 4-bytes, and added (2-u32):
Params encoding Locations Size Funcsec Size Total
==========================================================================
(1) param list, no dedup 1,017,654 5,467,824 6,485,478
(1) param list, w/ dedup 187,379 5,467,824 5,655,203
(2) param offsets u16, w/ dedup 14,526 5,324,888 5,339,414
(2) param offsets u32, w/ dedup 14,526 5,972,460 5,986,986
(3) param list inline, w/ align 0 5,172,268 5,172,268
(3)’s advantage is now much smaller.
(2)’s size also increased, either when using u32 for the offsets,
or using u16, but keeping in mind the BTF 4-bytes alignment.
