Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754062AbdCTKlk (ORCPT ); Mon, 20 Mar 2017 06:41:40 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:58016 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753602AbdCTKkn (ORCPT ); Mon, 20 Mar 2017 06:40:43 -0400 Date: Mon, 20 Mar 2017 11:39:37 +0100 From: Peter Zijlstra To: David Miller Cc: herbert@gondor.apana.org.au, 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 Message-ID: <20170320103937.lq7nfnutupr3gkn7@hirez.programming.kicks-ass.net> References: <1489767196.28631.305.camel@edumazet-glaptop3.roam.corp.google.com> <20170318164759.GA23837@gondor.apana.org.au> <20170318.182121.439615057765380575.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170318.182121.439615057765380575.davem@davemloft.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1043 Lines: 25 On Sat, Mar 18, 2017 at 06:21:21PM -0700, David Miller wrote: > From: Herbert Xu > Date: Sun, 19 Mar 2017 00:47:59 +0800 > > > Eric Dumazet wrote: > >> On Fri, 2017-03-17 at 07:42 +0000, Reshetova, Elena wrote: > >> > >>> Should we then first measure the actual numbers to understand what we > >>> are talking here about? > >>> I would be glad to do it if you suggest what is the correct way to do > >>> measurements here to actually reflect the real life use cases. > >> > >> How have these patches been tested in real life exactly ? > >> > >> Can you quantify number of added cycles per TCP packet, where I expect > >> we have maybe 20 atomic operations in all layers ... > > > > I completely agree. I think this thing needs to default to the > > existing atomic_t behaviour. > > I totally agree as well, the refcount_t facility as-is is unacceptable > for networking. Can we at least give a benchmark and have someone run numbers? We should be able to quantify these things.