On Fri, Jan 11, 2019 at 01:33:44PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Jan 10, 2019 at 03:09:49PM -0300, Arnaldo Carvalho de Melo escreveu: > > This last one is interesting, was this done on purpose? I think one > > level of indirection more and we would keep the original expressiveness. > > > > @@ -8473,7 +8497,7 @@ > > struct lruvec_stat * lruvec_stat_cpu; /* 136 8 */ > > atomic_long_t lruvec_stat[30]; /* 144 240 */ > > /* --- cacheline 6 boundary (384 bytes) --- */ > > - long unsigned int lru_zone_size[5][5]; /* 384 200 */ > > + long unsigned int lru_zone_size[25]; /* 384 200 */ > > /* --- cacheline 9 boundary (576 bytes) was 8 bytes ago --- */ > > So I see this is something inherited from CTF, that is why when I worked > on making these tools support multiple debugging file formats I added > this option: > > [acme@quaco pahole]$ pahole --flat_arrays -C mem_cgroup_per_node -F dwarf ~/git/build/v4.20-rc5+/net/ipv4/tcp.o > /tmp/dwarf > [acme@quaco pahole]$ pahole -C mem_cgroup_per_node -F btf ~/git/build/v4.20-rc5+/net/ipv4/tcp.o > /tmp/btf > [acme@quaco pahole]$ diff -u /tmp/dwarf /tmp/btf > [acme@quaco pahole]$ > > But do we want to keep it this way? I think ideally we should have multi-dimensional array. For tracing and bpf_probe_read use case, I think the offset will stay the same though. Yonghong, thoughts? The current flatten way in BTF is to avoid the type_id drifting. To encode multi-dimensionall array, more than one extra btf_type has to be added which will cause the drift.
