Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760409AbdCVOy5 (ORCPT ); Wed, 22 Mar 2017 10:54:57 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34668 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759588AbdCVOyR (ORCPT ); Wed, 22 Mar 2017 10:54:17 -0400 Message-ID: <1490194444.16816.154.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t From: Eric Dumazet To: Peter Zijlstra 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 Date: Wed, 22 Mar 2017 07:54:04 -0700 In-Reply-To: <20170322143329.ya5jnretfptf4iud@hirez.programming.kicks-ass.net> References: <20170320131629.GA26405@gondor.apana.org.au> <20170320132357.acygo3umw6fiwb4p@hirez.programming.kicks-ass.net> <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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 600 Lines: 16 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. 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.