Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935340AbdCVPJJ (ORCPT ); Wed, 22 Mar 2017 11:09:09 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52392 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934385AbdCVPJE (ORCPT ); Wed, 22 Mar 2017 11:09:04 -0400 Date: Wed, 22 Mar 2017 16:08:47 +0100 From: Peter Zijlstra To: Eric Dumazet Cc: Kees Cook , Herbert Xu , David Miller , "Reshetova, Elena" , Network Development , bridge@lists.linux-foundation.org, LKML , Alexey Kuznetsov , James Morris , Patrick McHardy , Stephen Hemminger , Hans Liljestrand , David Windsor , Andrew Morton Subject: Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Message-ID: <20170322150847.rsvhkbft3bn35rim@hirez.programming.kicks-ass.net> References: <20170320132713.GA26954@gondor.apana.org.au> <20170320134017.h3c2jrsnd4guuyu7@hirez.programming.kicks-ass.net> <1490131389.16816.123.camel@edumazet-glaptop3.roam.corp.google.com> <1490148199.16816.126.camel@edumazet-glaptop3.roam.corp.google.com> <20170322122540.odnm4j3r4c4uf7wt@hirez.programming.kicks-ass.net> <1490188936.16816.143.camel@edumazet-glaptop3.roam.corp.google.com> <20170322143329.ya5jnretfptf4iud@hirez.programming.kicks-ass.net> <1490194444.16816.154.camel@edumazet-glaptop3.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1490194444.16816.154.camel@edumazet-glaptop3.roam.corp.google.com> 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: 924 Lines: 22 On Wed, Mar 22, 2017 at 07:54:04AM -0700, Eric Dumazet wrote: > On Wed, 2017-03-22 at 15:33 +0100, Peter Zijlstra wrote: > > > > > But I would feel a whole lot better about the entire thing if we could > > measure their impact. It would also give us good precedent to whack > > other potential users of _nocheck over the head with -- show numbers. > > I wont be able to measure the impact on real workloads, our productions > kernels are based on 4.3 at this moment. Is there really no micro bench that exercises the relevant network paths? Do you really fully rely on Google production workloads? > I guess someone could code a lib/test_refcount.c launching X threads > using either atomic_inc or refcount_inc() in a loop. > > That would give a rough estimate of the refcount_t overhead among > various platforms. Its also a fairly meaningless number. It doesn't include any of the other work the network path does.