Herbert Xu
2017-Mar-20 13:16 UTC
[Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t
On Mon, Mar 20, 2017 at 11:39:37AM +0100, Peter Zijlstra wrote:> > 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. Cheers, -- Email: Herbert Xu <herbert at gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Peter Zijlstra
2017-Mar-20 13:23 UTC
[Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t
On Mon, Mar 20, 2017 at 09:16:29PM +0800, Herbert Xu wrote:> On Mon, Mar 20, 2017 at 11:39:37AM +0100, Peter Zijlstra wrote: > > > > 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.So what bench/setup do you want ran?
Herbert Xu
2017-Mar-20 13:27 UTC
[Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t
On Mon, Mar 20, 2017 at 02:23:57PM +0100, Peter Zijlstra wrote:> > 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. Cheers, -- Email: Herbert Xu <herbert at gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
David Laight
2017-Mar-20 14:10 UTC
[Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t
From: Herbert Xu> Sent: 20 March 2017 13:16 > On Mon, Mar 20, 2017 at 11:39:37AM +0100, Peter Zijlstra wrote: > > > > 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