[Bug bpf/23476] New: bpf statistical aggregates

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=23476

Bug ID: 23476
Summary: bpf statistical aggregates
Product: systemtap
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bpf
Assignee: systemtap at sourceware dot org
Reporter: me at serhei dot io
Target Milestone: ---

From the 'language features' brainstorm:

# Statistical aggregates

These can be implemented with BPF_MAP_TYPE_PERCPU storing elements of type
struct stat_data. Multiple aggregates can be stored in the same array, one per
aggregate.

Then __stp_stat_add can be implemented in kernel-space as non-looping,
non-locking eBPF code, while all other functions (reading stat value, histogram
printing) can be implemented as userspace helpers that aggregate data from all
CPUs.

As far as I can tell, it is not strictly necessary to lock a statistical
aggregate when reading its value -- the kernel-module backend does this to
guarantee a time-consistent snapshot of the different CPU's values, whereas
without locking the result might be approximate.

# {TODO} More complex structures: arrays of statistical aggregates

Still investigating whether we can do this.

(0) There is no per-CPU version of BPF_HASH.

(1) A BPF_MAP_TYPE_PERCPU would be a contiguously indexed, preallocated array
of aggregates, so a BPF_MAP_TYPE_HASH would be needed to map from sparse keys
to indices into the BPF_MAP_TYPE_PERCPU. However, without synchronization,
there is no way to allocate slots in the BPF_MAP_TYPE_PERCPU.

(2) /usr/include/linux/bpf.h mentions BPF_MAP_TYPE_HASH_OF_MAPS, but it's
currently undocumented. Still need to read the code and investigate if it works
for our purposes.

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=23476

Serhei Makarov <me at serhei dot io> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|systemtap at sourceware dot org |me at serhei dot io