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: David Laight <hidden>
Date: 2017-03-20 14:15:43
Also in: bridge, lkml

From: Herbert Xu
Sent: 20 March 2017 13:16
On Mon, Mar 20, 2017 at 11:39:37AM +0100, Peter Zijlstra wrote:
quoted
Can we at least give a benchmark and have someone run numbers? We should
be able to quantify these things.
Do you realise how many times this thing gets hit at 10Gb/s or
higher? Anyway, since you're proposing this change you should
demonstrate that it does not cause a performance regression.
What checks does refcnt_t actually do?

An extra decrement is hard to detect since the item gets freed early.
I guess making the main 'allocate/free' code hold (say) 64k references
would give some leeway for extra decrements.

An extra increment will be detected when the count eventually wraps.
Unless the error is in a very common path that won't happen for a long time.

On x86 the cpu flags from the 'lock inc/dec' could be used to reasonably
cheaply detect errors - provided you actually generate a forwards branch.

Otherwise having a common, but not every packet, code path verify that the
reference count is 'sane' would give reasonable coverage.

	David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help