Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755251AbdCTOPn convert rfc822-to-8bit (ORCPT ); Mon, 20 Mar 2017 10:15:43 -0400 Received: from smtp-out4.electric.net ([192.162.216.184]:54967 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754634AbdCTOPZ (ORCPT ); Mon, 20 Mar 2017 10:15:25 -0400 From: David Laight To: "'Herbert Xu'" , Peter Zijlstra CC: David Miller , "eric.dumazet@gmail.com" , "elena.reshetova@intel.com" , "keescook@chromium.org" , "netdev@vger.kernel.org" , "bridge@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "kuznet@ms2.inr.ac.ru" , "jmorris@namei.org" , "kaber@trash.net" , "stephen@networkplumber.org" , "ishkamiel@gmail.com" , "dwindsor@gmail.com" , "akpm@linux-foundation.org" Subject: RE: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Topic: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Index: AQHSoX+uGs2em8L41kmtByMJ2iW25KGdwQxg Date: Mon, 20 Mar 2017 14:10:24 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DCFFB5483@AcuExch.aculab.com> References: <1489767196.28631.305.camel@edumazet-glaptop3.roam.corp.google.com> <20170318164759.GA23837@gondor.apana.org.au> <20170318.182121.439615057765380575.davem@davemloft.net> <20170320103937.lq7nfnutupr3gkn7@hirez.programming.kicks-ass.net> <20170320131629.GA26405@gondor.apana.org.au> In-Reply-To: <20170320131629.GA26405@gondor.apana.org.au> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1089 Lines: 27 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