ast wrote earlier:
> [...]
> dtrace/systemtap/ktap approach is to use one script file that should provide
> all desired functionality. That architectural decision overcomplicated their
> implementations.
>
> eBPF follows split model: everything that needs to process millions of events
> per second needs to run in kernel and needs to be short and deterministic,
> all other things like aggregation and nice graphs should run in user space.
> [...]
For the record, this is not entirely accurate as to dtrace. dtrace
delegates aggregation and most reporting to userspace. Also,
systemtap is "short and deterministic" even for aggregations & nice
graphs, but since it limits its storage & cpu consumption, its
arrays/reports cannot get super large.
> [...]
> +SEC("events/skb/kfree_skb")
> +int bpf_prog2(struct bpf_context *ctx)
> +{
> +[...]
> + value = bpf_map_lookup_elem(&my_map, &loc);
> + if (value)
> + (*(long *) value) += 1;
> + else
> + bpf_map_update_elem(&my_map, &loc, &init_val);
> + return 0;
> +}
What kind of locking/serialization is provided by the ebpf runtime
over shared variables such as my_map?
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
