From patchwork Mon Oct 31 15:16:46 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 9405677 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1210A601C0 for ; Mon, 31 Oct 2016 15:16:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 10DF42856A for ; Mon, 31 Oct 2016 15:16:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 026E428990; Mon, 31 Oct 2016 15:16:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8A6BE2856A for ; Mon, 31 Oct 2016 15:16:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943946AbcJaPQv (ORCPT ); Mon, 31 Oct 2016 11:16:51 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:36321 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S943932AbcJaPQt (ORCPT ); Mon, 31 Oct 2016 11:16:49 -0400 Received: by mail-pf0-f193.google.com with SMTP id n85so8990181pfi.3; Mon, 31 Oct 2016 08:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=Z4sEUueC/AroL0L+yFTkCPLqk6JvqCjehwKIcGpdXy0=; b=gnue7UGA2S+Req/BfUvTyB7cZCS+f3gf5iYyv6ywJ20aLyEExXKWO0qVMcD1g9kRSt GJbv+K50olygeCB5TO4g0qaAoNx8HQM1RpkoAbPLQqM/iHcHY65NzXHwUAs000hQLrfx 8JiLe4drKHzlKUaIjLz1Opp4USlsaD0jJ7vi/w9FhEyIYv5Tn36yj3cUkkUvO7NAsYqp EqiyDifDbG++jwxe7RZimqSGIWnxC8lvJGCC/YqrzZMfXMA25RDAToC684NZ08mShX3Z hBhaR8MhZRvRJqIsD29ghxzrCsXCvx5qyfIplNYGLTAGmgaJwy58A23js1p6TaxKJuy0 Azfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=Z4sEUueC/AroL0L+yFTkCPLqk6JvqCjehwKIcGpdXy0=; b=bfCvojPwZtzlEtRMv7BDq6S/rIoGzzP0K+jBIsJwaigRLFrsh3n4fCH9RblyFpBCYI Fd/kLlondH7ygswgWrjByPK8sKD0vbbF11ZFgxCY6H0M4SvI9XyrT04rMg5INfwdSIzW uE2LO22vygpBJ7XrOp/EJqgtPLnFIGtoqUpsm0n/WhgddeEMNkkhFM9dRCw6Q+o9nBWJ H7r4/wxfYsZndYMzGOpALs/L083UqOzXA34XE9ote5BKmq9TTGmwk+tz+9zZdSO7GvfS 4Q9vzObcBMp0dKPqQddV5szj7szzpqAYzq3eaApVl/pYYG4z6AsfV786agk/SZ79VHZL AdWg== X-Gm-Message-State: ABUngvcVa+uTduqNZSq7A6SRozvSUH5mZZJlSiWF7qgoa7qSD7MqjwXPZUptL5nKJ9HEGw== X-Received: by 10.99.226.83 with SMTP id y19mr41956811pgj.147.1477927008602; Mon, 31 Oct 2016 08:16:48 -0700 (PDT) Received: from ?IPv6:2620:0:1000:1704:7d34:a419:244d:86b9? ([2620:0:1000:1704:7d34:a419:244d:86b9]) by smtp.googlemail.com with ESMTPSA id 13sm6639625pfz.30.2016.10.31.08.16.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 08:16:47 -0700 (PDT) Message-ID: <1477927006.7065.304.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [PATCH net-next] udp: do fwd memory scheduling on dequeue From: Eric Dumazet To: Paolo Abeni Cc: netdev@vger.kernel.org, "David S. Miller" , James Morris , Trond Myklebust , Alexander Duyck , Daniel Borkmann , Eric Dumazet , Tom Herbert , Hannes Frederic Sowa , linux-nfs@vger.kernel.org Date: Mon, 31 Oct 2016 08:16:46 -0700 In-Reply-To: <1477926132.6655.10.camel@redhat.com> References: <95bb1b780be2e35ff04fb9e1e2c41470a0a15582.1477660091.git.pabeni@redhat.com> <1477674975.7065.245.camel@edumazet-glaptop3.roam.corp.google.com> <1477677030.7065.250.camel@edumazet-glaptop3.roam.corp.google.com> <1477729045.5306.11.camel@redhat.com> <1477745013.7065.270.camel@edumazet-glaptop3.roam.corp.google.com> <1477926132.6655.10.camel@redhat.com> X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 2016-10-31 at 16:02 +0100, Paolo Abeni wrote: > > No problem at all with incremental patches ;-) > > In our experiment, touching udp_memory_allocated is only a part of the > the source of contention, with the biggest source of contention being > the sk_rmem_alloc update - which happens on every dequeue. > > We experimented doing fwd alloc of the whole sk_rcvbuf; even in that > scenario we hit relevant contention if sk_rmem_alloc update was done > under the lock, while full sk_rcvbuf forward allocation and > sk_rmem_alloc update outside the spinlock gave very similar performance > to our posted patch. > I think that the next step (after the double lock on dequeue removal) > should be moving sk_rmem_alloc outside the lock: the needed changes for > doing that on top of double lock on dequeue removal are very small > (would add ~10 lines of code). > During my load tests, one of the major factor was sk_drops being incremented like crazy, dirtying a critical cache line, hurting sk_filter reads for example. /* --- cacheline 6 boundary (384 bytes) --- */ struct { atomic_t rmem_alloc; /* 0x180 0x4 */ int len; /* 0x184 0x4 */ struct sk_buff * head; /* 0x188 0x8 */ struct sk_buff * tail; /* 0x190 0x8 */ } sk_backlog; /* 0x180 0x18 */ int sk_forward_alloc; /* 0x198 0x4 */ __u32 sk_txhash; /* 0x19c 0x4 */ unsigned int sk_napi_id; /* 0x1a0 0x4 */ unsigned int sk_ll_usec; /* 0x1a4 0x4 */ atomic_t sk_drops; /* 0x1a8 0x4 */ int sk_rcvbuf; /* 0x1ac 0x4 */ struct sk_filter * sk_filter; /* 0x1b0 0x8 */ union { struct socket_wq * sk_wq; /* 0x8 */ struct socket_wq * sk_wq_raw; /* 0x8 */ }; /* 0x1b8 0x8 */ I was playing moving this field elsewhere and not reading it if not necessary. --- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/net/sock.h b/include/net/sock.h index f13ac87a8015cb18c5d3fe5fdcf2d6a0592428f4..a901df591eb45e153517cdb8b409b61563d1a4e3 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@ -2112,7 +2112,8 @@ struct sock_skb_cb { static inline void sock_skb_set_dropcount(const struct sock *sk, struct sk_buff *skb) { - SOCK_SKB_CB(skb)->dropcount = atomic_read(&sk->sk_drops); + SOCK_SKB_CB(skb)->dropcount = sock_flag(sk, SOCK_RXQ_OVFL) ? + atomic_read(&sk->sk_drops) : 0; } static inline void sk_drops_add(struct sock *sk, const struct sk_buff *skb)