Hi, On 10/13/2022 1:07 PM, Martin KaFai Lau wrote: > 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. Understand. Yes, if using the newly added rcu_trace_implies_rcu_gp(), there will be no space overhead. I will use the rcu_trace_implies_rcu_gp()-way in all these cases and defer the use of RCU polling APIs to future work.
