Thread (17 messages) flat view 17 messages, 3 authors, 2016-01-12

Re: [PATCH net-next 0/4] bpf: bpf_htab: Add BPF_MAP_TYPE_PERCPU_HASH

From: Alexei Starovoitov <hidden>
Date: 2016-01-12 06:00:08
Also in: lkml

On Tue, Jan 12, 2016 at 01:48:10PM +0800, Ming Lei wrote:
The total memory consumption is still much less than memory consumed
by percpu hash since a new element is only added to hash if the key is run
on that CPU. Most of times, for one key it may touch very few CPUs.

For percpu hash, the memory is always allocated to every CPU no matter
if the key is run from the CPU.
In Martin's use case all cpus are servicing network traffic and all of them
are counting packets.
In my test, removing the current kmalloc() in update element callback can
improve io thoughput by 10% not mention the percpu ida allocation cost, and
looks it isn't cheap. That is why I don't think it is good to
introduce another new
allocation in the eBPF prog path.
I don't think anyone is arguing that pre-allocation is not needed.
In some cases better performance can be achieved with pre-allocation,
in some other cases regular hash map will be enough,
and in others hash map with per-cpu is needed as well.
You can find my test in the link below:

       https://patchwork.ozlabs.org/patch/556926/
yes, for tools/biolatency pre-allocation is a win,
but in many other cases we simply cannot pre-allocate all elements.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help