Might be a bug using bpf_timer on Hashmap? With same setups using bpf_timer but with LRU_Hashmap, the memory usage is way better: see following with LRU_Hashmap 16M capacity, 1 minute bpf_timer callback/cleanup.. (pre-allocation ~5G), memory usage peaked ~7G (Flat and does not fluctuate - unlike Hashmap) 32M capacity, 1 minute bpf_timer callback/cleanup.. (pre-allocation ~8G), memory usage peaked ~12G (Flat and does not fluctuate - unlike Hashmap) On Thu, Mar 16, 2023 at 6:22 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Mar 16, 2023 at 12:18 PM Chris Lai <chrlai@xxxxxxxxxxxxx> wrote: > > > > Hello, > > Using BPF Hashmap with bpf_timer for each entry value and callback to > > delete the entry after 1 minute. > > Constantly creating load to insert elements onto the map, we have > > observed the following: > > -3M map capacity, 1 minute bpf_timer callback/cleanup, memory usage > > peaked around 5GB > > -16M map capacity, 1 minute bpf_timer callback/cleanup, memory usage > > peaked around 34GB > > -24M map capacity, 1 minute bpf_timer callback/cleanup, memory usage > > peaked around 55GB > > Wondering if this is expected and what is causing the huge increase in > > memory as we increase the number of elements inserted onto the map. > > Thank you. > > That's not normal. Do you have a small reproducer?