On 10/12/22 6:25 PM, Hou Tao wrote:
Back to the polling API. Are these things freed individually, or can
they be grouped? If they can be grouped, the storage for the grace-period
state could be associated with the group.
As said above, for bpf memory allocator it may be OK because it frees elements
in batch, but for bpf local storage and its element these memories are freed
individually. So I think if the implication of RCU tasks trace grace period will
not be changed in the foreseeable future, adding rcu_trace_implies_rcu_gp() and
using it in bpf is a good idea. What do you think ?
Maybe the BPF memory allocator does it one way and BPF local storage
does it another way.
Why not. Maybe bpf expert think the space overhead is also reasonable in the BPF
local storage case.
There is only 8 bytes hole left in 'struct bpf_local_storage_elem', so it is
precious. Put aside the space overhead, only deletion of a local storage
requires call_rcu_tasks_trace(). The common use case for local storage is to
alloc once and stay there for the whole life time of the sk/task/inode. Thus,
delete should happen very infrequent.
It will still be nice to optimize though if it does not need extra space and
that seems possible from reading the thread.
