From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56620C43381 for ; Fri, 22 Mar 2019 16:37:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 189342190A for ; Fri, 22 Mar 2019 16:37:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qty+ayAB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727388AbfCVQhn (ORCPT ); Fri, 22 Mar 2019 12:37:43 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:36286 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726980AbfCVQhm (ORCPT ); Fri, 22 Mar 2019 12:37:42 -0400 Received: by mail-ed1-f67.google.com with SMTP id e4so2213000edi.3 for ; Fri, 22 Mar 2019 09:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=43xdGI+Q6HbDNr5+tKy0RhY5i7QZMLmRkYy57OKMToI=; b=Qty+ayAB2KnQhr6/f8XYmai0cMgMtRgKJ4Y3MMr3ADc401gq2rLo9p0qymCwD142GS hNey35OMYSfNHCVseV0furXb4J/DAqNJ3KwijIKve4cVUgEDfLxG/ri9Z3GmhdJlfco8 +OktRRVT0uK+juTgySNjbm1jOMyGYVS16/ZqD9lmCW/Vcg4/IJ0Zg50J8o6LitQeELD+ /QMgOnG+mgO+guqgqM689TmZrKN5I67sljoR1ottefGqlJMwT0DVGKVZrrAurl/AiDsU FkAhCUT4+f3LiEvdHkf0j02AYkHmG6t7AwOHD5trDBnmasktsf8zXJOGj2TerGJ7Q0Sw uA7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=43xdGI+Q6HbDNr5+tKy0RhY5i7QZMLmRkYy57OKMToI=; b=EJCMsZjjnLsqYwGNmtC8esM/ftubN/bZOG5ZYEBZttt6vl48Qt+hwu1XOgy77UabMj EfElgktlPxFoB3SgiDZHh0rbRsprnaaOLdujF8VhRDZ12+7A+zaqyXL+lqxhreiyrW+l +bfXDM5V9jwIXhP/HJhxzDQXKKf8EtJuavNafkx3kFDqcJvkeJZw+G1gJ0BzXtMY3cY7 cjb/0k99f3T25Hr7ULGgJIYyVOMgecPJLSkbDGRSwUDD3mZv6BczIrcLTJRpptaGCQoP 1kCvFdBHBnX9mi2FFZ6NfllLhtTYXoweAzQ/Ee1wzKAg6g7QNsLrXYHu06+VwvNVFAzJ RLEA== X-Gm-Message-State: APjAAAXBh86+IauhnrwOfwLCQ8Q8Ter10iuS6YfPyiyOdNgT00yM8jiO LzNkfhOnv86UhZDmqR9Kl6w= X-Google-Smtp-Source: APXvYqyq/g7pr2QgX7bSafckwGcrcECuyuOxBgjzMiXM2H/+Y3jQtTpqYeMGSvipFILa6hZ0gOE2lw== X-Received: by 2002:a50:a4d5:: with SMTP id x21mr7144947edb.189.1553272661320; Fri, 22 Mar 2019 09:37:41 -0700 (PDT) Received: from [172.31.98.139] ([195.39.71.253]) by smtp.gmail.com with ESMTPSA id 50sm2768316edz.73.2019.03.22.09.37.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 09:37:40 -0700 (PDT) From: Tariq Toukan Subject: Re: [PATCH v3 net-next 0/3] tcp: add rx/tx cache to reduce lock contention To: Eric Dumazet , "David S . Miller" Cc: netdev , Eric Dumazet References: <20190322155640.248144-1-edumazet@google.com> Message-ID: <63a235a6-a18f-7c64-8209-f89756efd22f@gmail.com> Date: Fri, 22 Mar 2019 18:37:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190322155640.248144-1-edumazet@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/22/2019 5:56 PM, Eric Dumazet wrote: > On hosts with many cpus we can observe a very serious contention > on spinlocks used in mm slab layer. > > The following can happen quite often : > > 1) TX path > sendmsg() allocates one (fclone) skb on CPU A, sends a clone. > ACK is received on CPU B, and consumes the skb that was in the retransmit > queue. > > 2) RX path > network driver allocates skb on CPU C > recvmsg() happens on CPU D, freeing the skb after it has been delivered > to user space. > > In both cases, we are hitting the asymetric alloc/free pattern > for which slab has to drain alien caches. At 8 Mpps per second, > this represents 16 Mpps alloc/free per second and has a huge penalty. > > In an interesting experiment, I tried to use a single kmem_cache for all the skbs > (in skb_init() : skbuff_fclone_cache = skbuff_head_cache = > kmem_cache_create("skbuff_fclone_cache", sizeof(struct sk_buff_fclones),); > qnd most of the contention disappeared, since cpus could better use > their local slab per-cpu cache. > > But we can do actually better, in the following patches. > > TX : at ACK time, no longer free the skb but put it back in a tcp socket cache, > so that next sendmsg() can reuse it immediately. > > RX : at recvmsg() time, do not free the skb but put it in a tcp socket cache > so that it can be freed by the cpu feeding the incoming packets in BH. > > This increased the performance of small RPC benchmark by about 10 % on a host > with 112 hyperthreads. > Hi Eric, Does this have any effect on non tcp traffic?