Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp925700yba; Thu, 18 Apr 2019 11:56:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlbBFTy/a6b+AeWgz4fAXlTLK24O8I3GJxkJwCKd86zee8z/blteuL8xSM3Rq1c7voH7JH X-Received: by 2002:a17:902:a582:: with SMTP id az2mr7982312plb.315.1555613796917; Thu, 18 Apr 2019 11:56:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555613796; cv=none; d=google.com; s=arc-20160816; b=n/SlM0pH8oFQLOPbw34+eBS9rfBLFKBZ7lFRSoQamGdbGmXDJ4+9vo8Czoel1mjAQW /Mf4CUQFz00tqLqu4VQsbK/acwqHJ+FA6yOHNUEaoWoF+cFf1FWlXlIHBcpEKO1VRU/D /NsU+SxZ/BD9ovW7k/eTW1823JBk/KOPTRwUlwTPClWDKAafKh+7eqk8nXtCwyZpcs8I T3P2XG9uf0FoLOwIp6Tj7lBP0s8tLdTIH1uXl7fVGCSBn3nWSme/34/5rtBIr5G4L0BK WFioYouUCq/S+iL15eTrdQW7Cu1Imij29ZiBPTRVR4m8fsTnj2WgVrob3XBiDmvGLQur HKbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=CL7YPgtpATg65qwjLk5h6Xiz5vMP2lObV+iUgz87oJw=; b=JpTFDnbuyZx21nhvTxtsiHmxyLM5VwB7uN7ewQzYBr4k1oH6BAmz5EMKw+bLSzCbem 6kwNnop8Od/f1TbNc822K+M5CeM2GThi1QoUks+xsd0V2YPaaZz1YLQ/gNV49O2hzD1Q 0glnXNTzFP95egn7rmsLzVmvhJmsdVD6FABPqgtmjHSYzEghSryyoj8hPMJMv6TtiJf8 YNw2uxolrRSWm02SJAr+MkMr4SgorJTgAZp9tpICZ38gHGPVTLPrgG1OAsnBhEl+64sK un4ed3UEpFGm8ExXDA4gNhUm919Ip/SZLMPfNFPrMDFzjR2KTunQfbq1qvBndeUaFGMW ZxFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k9amOKGz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e14si2836750pfn.203.2019.04.18.11.56.19; Thu, 18 Apr 2019 11:56:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k9amOKGz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732981AbfDRSzU (ORCPT + 99 others); Thu, 18 Apr 2019 14:55:20 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:42718 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbfDRSzU (ORCPT ); Thu, 18 Apr 2019 14:55:20 -0400 Received: by mail-pg1-f193.google.com with SMTP id p6so1591905pgh.9; Thu, 18 Apr 2019 11:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CL7YPgtpATg65qwjLk5h6Xiz5vMP2lObV+iUgz87oJw=; b=k9amOKGzKtxdIhjKvnMl0Y7bGvyhx9WH4Cv2/w5orp1X2UUzBEEDZh01vlLvpKJHOF 8iCtopgnmvTSKaz0rce8TWtJL5E6jVrx2m0kNlaTENlw3oM3nwb3tHGjglp7Gq0ipxoV Jhdz7cHpUEdCqINahBAI+xYi/U26zSLJaZsCdon/8f2/EjjSLY8HzD9xapKWy/ZbqAUV cHCbWrYpKQYtD8DZEAmpDYYTezYKFQwgr+JzW69w7Rm+Ofg1fdzHApiG2y3fju8XPX5R xZ3MqYw0QNqHlKkXvnK0gab21Z5A4gkbN4DebB09xyb3oqX5I7xD2WSTPc4ifqpNF441 jFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CL7YPgtpATg65qwjLk5h6Xiz5vMP2lObV+iUgz87oJw=; b=StL9UbFJUah0a7F2mhzAEsP/MGZ3Sm1J207g4G07fhoqHa1lWwFGQPW9HkbjkcSlQ6 aPkTKz7GEUQ1N1u13EJOAvc4HJ5oQ/6jx8hr1ZgWdJ9a7REce0M7MCZm+Pe42Cv+P0he jaoVsHanIoCrCH0tv47CsvJzR2xOWiWwKpRmPy5XDEEm9jHroreXOMJncG5eq36Vc1vZ ONNvXBdLvhrrn80X5J6N6K9fL5iIgKiW9zujlBBkE2Y16Qcj9YdDlpBMQbrp3PDkKI2k /Oldad4q1kaTdG79pyZR8ER28jsAaxYLD1FzLEl365PhJ/6hcknynzJ6mKx1bh46mXKn Yxpg== X-Gm-Message-State: APjAAAW22brX1XDQGOgFUfogibeYL6EkKm3NUkEeh/ATXZCh7zFLygGK XJJqBImZUkCVV0ehy8KiDseowhWa X-Received: by 2002:a65:64cf:: with SMTP id t15mr87820579pgv.322.1555613719036; Thu, 18 Apr 2019 11:55:19 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id j16sm3730481pfi.58.2019.04.18.11.55.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 11:55:17 -0700 (PDT) Subject: Re: [PATCH 1/4] net/skbuff: don't waste memory reserves To: Andrey Ryabinin , "David S. Miller" Cc: Eric Dumazet , Mel Gorman , Willem de Bruijn , Florian Westphal , linux-kernel@vger.kernel.org, netdev@vger.kernel.org References: <20190418180524.23489-1-aryabinin@virtuozzo.com> From: Eric Dumazet Message-ID: <791f4f23-d931-4ac8-4e60-3ffe46c4ece2@gmail.com> Date: Thu, 18 Apr 2019 11:55:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190418180524.23489-1-aryabinin@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/18/2019 11:05 AM, Andrey Ryabinin wrote: > In some workloads we have noticed packets being dropped by > sk_filter_trim_cap() because the 'skb' was allocated from pfmemalloc > reserves: > > /* > * If the skb was allocated from pfmemalloc reserves, only > * allow SOCK_MEMALLOC sockets to use it as this socket is > * helping free memory > */ > if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) { > NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP); > return -ENOMEM; > } > > Memalloc sockets are used for stuff like swap over NBD or NFS > and only memalloc sockets can process memalloc skbs. Since we > don't have any memalloc sockets in our setups we shouldn't have > memalloc skbs either. It simply doesn't make any sense to waste > memory reserves on skb which will be dropped anyway. > > It appears that __dev_alloc_pages() unconditionally uses > __GFP_MEMALLOC, so unless caller added __GFP_NOMEMALLOC, the > __dev_alloc_pages() may dive into memory reserves. > Later build_skb() or __skb_fill_page_desc() sets skb->pfmemalloc = 1 > so this skb always dropped by sk_filter_trim_cap(). > > Instead of wasting memory reserves we simply shouldn't use them in the > case of absence memalloc sockets in the system. Do this by adding > the __GFP_MEMALLOC only when such socket is present in the system. > > Fixes: 0614002bb5f7 ("netvm: propagate page->pfmemalloc from skb_alloc_page to skb") > Signed-off-by: Andrey Ryabinin > --- > include/linux/skbuff.h | 17 ++++++++++++++++- > include/net/sock.h | 15 --------------- > 2 files changed, 16 insertions(+), 16 deletions(-) > Hi Andrey Are you targeting net or net-next tree ? AFAIK, drivers allocate skbs way before a frame is actually received, (at RX ring buffer initialization or refill) So sk_memalloc_socks() might be false at that time, but true later.