Hi, On 7/6/2023 8:25 PM, Anton Protopopov wrote: > On Thu, Jul 06, 2023 at 10:01:26AM +0800, Hou Tao wrote: >> Hi, >> >> On 7/4/2023 10:34 PM, Anton Protopopov wrote: >>> On Tue, Jul 04, 2023 at 09:56:36PM +0800, Hou Tao wrote: SNIP >>>> by introducing a new map flag ? >>> Per-map-flag or a static key? For me it looked like just doing an unconditional >>> `inc` for a per-cpu variable is better vs. doing a check then `inc` or an >>> unconditional jump. >> Sorry I didn't make it clear that I was worried about the allocated >> per-cpu memory. Previous I thought the per-cpu memory is limited, but >> after did some experiments I found it was almost the same as kmalloc() >> which could use all available memory to fulfill the allocation request. >> For a host with 72-cpus, the memory overhead for 10k hash map is about >> ~6MB. The overhead is tiny compared with the total available memory, but >> it is avoidable. > So, in my first patch I've only added new counters for preallocated maps. But > then the feedback was that we need a generic percpu inc/dec counters, so I > added them by default. For me a percpu s64 looks cheap enough for a hash map... Thanks for the explanation. Let's just allocate the per-cpu elem_count in hash map. If there are use cases which need to make it optional, we can revise that later. > .
