From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758358AbdCUVXZ (ORCPT ); Tue, 21 Mar 2017 17:23:25 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34275 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758303AbdCUVXW (ORCPT ); Tue, 21 Mar 2017 17:23:22 -0400 Message-ID: <1490131389.16816.123.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: Kees Cook Cc: Peter Zijlstra , 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: Tue, 21 Mar 2017 14:23:09 -0700 In-Reply-To: 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> <20170320132357.acygo3umw6fiwb4p@hirez.programming.kicks-ass.net> <20170320132713.GA26954@gondor.apana.org.au> <20170320134017.h3c2jrsnd4guuyu7@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 On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > Yeah, this is exactly what I'd like to find as well. Just comparing > cycles between refcount implementations, while interesting, doesn't > show us real-world performance changes, which is what we need to > measure. > > Is Eric's "20 concurrent 'netperf -t UDP_STREAM'" example (from > elsewhere in this email thread) real-world meaningful enough? Not at all ;) This was targeting the specific change I had in mind for ip_idents_reserve(), which is not used by TCP flows. Unfortunately there is no good test simulating real-world workloads, which are mostly using TCP flows. Most synthetic tools you can find are not using epoll(), and very often hit bottlenecks in other layers. It looks like our suggestion to get kernel builds with atomic_inc() being exactly an atomic_inc() is not even discussed or implemented. Coding this would require less time than running a typical Google kernel qualification (roughly one month, thousands of hosts..., days of SWE). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Date: Tue, 21 Mar 2017 14:23:09 -0700 Message-ID: <1490131389.16816.123.camel@edumazet-glaptop3.roam.corp.google.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> <20170320132357.acygo3umw6fiwb4p@hirez.programming.kicks-ass.net> <20170320132713.GA26954@gondor.apana.org.au> <20170320134017.h3c2jrsnd4guuyu7@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Herbert Xu , Patrick McHardy , Peter Zijlstra , Network Development , bridge@lists.linux-foundation.org, LKML , James Morris , Hans Liljestrand , Alexey Kuznetsov , Andrew Morton , David Miller , "Reshetova, Elena" , David Windsor To: Kees Cook Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bridge-bounces@lists.linux-foundation.org Errors-To: bridge-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > Yeah, this is exactly what I'd like to find as well. Just comparing > cycles between refcount implementations, while interesting, doesn't > show us real-world performance changes, which is what we need to > measure. > > Is Eric's "20 concurrent 'netperf -t UDP_STREAM'" example (from > elsewhere in this email thread) real-world meaningful enough? Not at all ;) This was targeting the specific change I had in mind for ip_idents_reserve(), which is not used by TCP flows. Unfortunately there is no good test simulating real-world workloads, which are mostly using TCP flows. Most synthetic tools you can find are not using epoll(), and very often hit bottlenecks in other layers. It looks like our suggestion to get kernel builds with atomic_inc() being exactly an atomic_inc() is not even discussed or implemented. Coding this would require less time than running a typical Google kernel qualification (roughly one month, thousands of hosts..., days of SWE). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=MbhRis1i84PDaCQwNwRgdxEO402R/WzKiEy/M830NEw=; b=bvANNkEHwXp2/0/INp3P4ol5bYTRqK5Rkkk1VQLAF3jFNRqXLMfvlcsfWUcMkTcbrC EzHdzDYADIWrIf4ZCQj5LNr6NoUAXOstAFsDv64ryxXUFxRn1xlejexyNQdKwzRANtR9 HNEAoXAdIYDFedBWMUglE38EFY96eZzAvxJpq/RGx4JP5iLDvEQES5xjbsMDdHSP0R03 YWEb9ZV8V0whkxNusGWf/R0TZWa9/4QeXvPCIZSdbnRq4X1B48y+7qEoHbcx5Sc+MBra VNjx/ZvTJ0YfIGpiNbh4+gOot70471vH5Xp4COuqTnXF1XK8AeqCWvMlMs5E235B0LLS GhUA== Message-ID: <1490131389.16816.123.camel@edumazet-glaptop3.roam.corp.google.com> From: Eric Dumazet Date: Tue, 21 Mar 2017 14:23:09 -0700 In-Reply-To: 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> <20170320132357.acygo3umw6fiwb4p@hirez.programming.kicks-ass.net> <20170320132713.GA26954@gondor.apana.org.au> <20170320134017.h3c2jrsnd4guuyu7@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kees Cook Cc: Herbert Xu , Patrick McHardy , Peter Zijlstra , Network Development , bridge@lists.linux-foundation.org, LKML , James Morris , Hans Liljestrand , Alexey Kuznetsov , Andrew Morton , David Miller , "Reshetova, Elena" , David Windsor On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > Yeah, this is exactly what I'd like to find as well. Just comparing > cycles between refcount implementations, while interesting, doesn't > show us real-world performance changes, which is what we need to > measure. > > Is Eric's "20 concurrent 'netperf -t UDP_STREAM'" example (from > elsewhere in this email thread) real-world meaningful enough? Not at all ;) This was targeting the specific change I had in mind for ip_idents_reserve(), which is not used by TCP flows. Unfortunately there is no good test simulating real-world workloads, which are mostly using TCP flows. Most synthetic tools you can find are not using epoll(), and very often hit bottlenecks in other layers. It looks like our suggestion to get kernel builds with atomic_inc() being exactly an atomic_inc() is not even discussed or implemented. Coding this would require less time than running a typical Google kernel qualification (roughly one month, thousands of hosts..., days of SWE).