On Wed, Dec 16, 2015 at 7:10 AM, Alexei Starovoitov
wrote:
> On Tue, Dec 15, 2015 at 07:21:03PM +0800, Ming Lei wrote:
>> kmalloc() is often a bit time-consuming, also
>> one atomic counter has to be used to track the total
>> allocated elements, which is also not good.
>>
>> This patch pre-alloca
On 12/16/2015 12:35 AM, Daniel Borkmann wrote:
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+static int htab_init_elems_allocator(struct bpf_htab *htab)
+{
+int ret = htab_pre_alloc_elems(htab);
+
+if (ret)
+return ret;
+
+ret = percpu_ida_init(&htab->elems_pool, htab->map.max
On 12/16/2015 12:10 AM, Alexei Starovoitov wrote:
...
this rounding to cache line is great for performance, but it's extra
memory upfront which may not be needed. The per-allocation is a classic
performance vs memory trade-off. In other cases it may hurt.
So could you change the patch to do pre-a
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+static int htab_init_elems_allocator(struct bpf_htab *htab)
+{
+ int ret = htab_pre_alloc_elems(htab);
+
+ if (ret)
+ return ret;
+
+ ret = percpu_ida_init(&htab->elems_pool, htab->map.max_entries);
+ if (ret)
+
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+/* Called from syscall, and the code is borrowed from blk_mq */
+static int htab_pre_alloc_elems(struct bpf_htab *htab)
+{
+ const unsigned max_order = 4;
+ unsigned elem_size = htab->elem_size, i;
+ unsigned nr_entries = htab->map.ma
On Tue, Dec 15, 2015 at 07:21:03PM +0800, Ming Lei wrote:
> kmalloc() is often a bit time-consuming, also
> one atomic counter has to be used to track the total
> allocated elements, which is also not good.
>
> This patch pre-allocates element pool in htab_map_alloc(),
> then use percpu_ida to all
kmalloc() is often a bit time-consuming, also
one atomic counter has to be used to track the total
allocated elements, which is also not good.
This patch pre-allocates element pool in htab_map_alloc(),
then use percpu_ida to allocate one slot from the pool,
then the runtime allocation/freeing cost
