Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964855AbdCVPWj (ORCPT ); Wed, 22 Mar 2017 11:22:39 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:34535 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964834AbdCVPWa (ORCPT ); Wed, 22 Mar 2017 11:22:30 -0400 Message-ID: <1490196147.16816.162.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 08:22:27 -0700 In-Reply-To: <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> <20170322150847.rsvhkbft3bn35rim@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: 855 Lines: 21 On Wed, 2017-03-22 at 16:08 +0100, Peter Zijlstra wrote: > 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? You could run a synflood test, with ~10 Mpps. sock_hold() is definitely used in SYN handling. Last upstream kernels do not work on my lab hosts, for whatever reason.