Thread (54 messages) flat view 54 messages, 8 authors, 2017-03-22

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Eric Dumazet <hidden>
Date: 2017-03-20 15:25:43
Also in: bridge, lkml

On Mon, 2017-03-20 at 14:40 +0100, Peter Zijlstra wrote:
On Mon, Mar 20, 2017 at 09:27:13PM +0800, Herbert Xu wrote:
quoted
On Mon, Mar 20, 2017 at 02:23:57PM +0100, Peter Zijlstra wrote:
quoted
So what bench/setup do you want ran?
You can start by counting how many cycles an atomic op takes
vs. how many cycles this new code takes.
On what uarch?

I think I tested hand coded asm version and it ended up about double the
cycles for a cmpxchg loop vs the direct instruction on an IVB-EX (until
the memory bus saturated, at which point they took the same). Newer
parts will of course have different numbers,

Can't we run some iperf on a 40gbe fiber loop or something? It would be
very useful to have an actual workload we can run.
If atomic ops are converted one by one, it is likely that results will
be noise.

We can not start a global conversion without having a way to have
selective debugging ?

Then, adopting this fine infra would really not be a problem.

Some arches have efficient atomic_inc() ( no full barriers ) while load
+ test + atomic_cmpxchg() + test + loop" is more expensive.

PowerPC has no efficient atomic_inc() and this definitely shows on
network intensive workloads involving concurrent cores/threads.

atomic_cmpxchg() on PowerPC is horribly more expensive because of the
added two SYNC instructions.

networking performance is quite poor on PowerPC as of today.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help