From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by kanga.kvack.org (Postfix) with ESMTP id 489BA900015 for ; Thu, 11 Jun 2015 17:22:16 -0400 (EDT) Received: by igbsb11 with SMTP id sb11so12927281igb.0 for ; Thu, 11 Jun 2015 14:22:16 -0700 (PDT) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com. [2607:f8b0:4001:c05::241]) by mx.google.com with ESMTPS id ik8si217783igb.1.2015.06.11.14.22.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 14:22:15 -0700 (PDT) Received: by igdh15 with SMTP id h15so4865997igd.3 for ; Thu, 11 Jun 2015 14:22:15 -0700 (PDT) Message-ID: <1434057733.27504.52.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [RFC] net: use atomic allocation for order-3 page allocation From: Eric Dumazet Date: Thu, 11 Jun 2015 14:22:13 -0700 In-Reply-To: <5579FABE.4050505@fb.com> References: <71a20cf185c485fa23d9347bd846a6f4e9753405.1434053941.git.shli@fb.com> <1434055687.27504.51.camel@edumazet-glaptop2.roam.corp.google.com> <5579FABE.4050505@fb.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Chris Mason Cc: Shaohua Li , netdev@vger.kernel.org, davem@davemloft.net, Kernel-team@fb.com, Eric Dumazet , David Rientjes , linux-mm@kvack.org On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote: > On 06/11/2015 04:48 PM, Eric Dumazet wrote: > > On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote: > >> We saw excessive memory compaction triggered by skb_page_frag_refill. > >> This causes performance issues. Commit 5640f7685831e0 introduces the > >> order-3 allocation to improve performance. But memory compaction has > >> high overhead. The benefit of order-3 allocation can't compensate the > >> overhead of memory compaction. > >> > >> This patch makes the order-3 page allocation atomic. If there is no > >> memory pressure and memory isn't fragmented, the alloction will still > >> success, so we don't sacrifice the order-3 benefit here. If the atomic > >> allocation fails, compaction will not be triggered and we will fallback > >> to order-0 immediately. > >> > >> The mellanox driver does similar thing, if this is accepted, we must fix > >> the driver too. > >> > >> Cc: Eric Dumazet > >> Signed-off-by: Shaohua Li > >> --- > >> net/core/sock.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/net/core/sock.c b/net/core/sock.c > >> index 292f422..e9855a4 100644 > >> --- a/net/core/sock.c > >> +++ b/net/core/sock.c > >> @@ -1883,7 +1883,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t gfp) > >> > >> pfrag->offset = 0; > >> if (SKB_FRAG_PAGE_ORDER) { > >> - pfrag->page = alloc_pages(gfp | __GFP_COMP | > >> + pfrag->page = alloc_pages((gfp & ~__GFP_WAIT) | __GFP_COMP | > >> __GFP_NOWARN | __GFP_NORETRY, > >> SKB_FRAG_PAGE_ORDER); > >> if (likely(pfrag->page)) { > > > > This is not a specific networking issue, but mm one. > > > > You really need to start a discussion with mm experts. > > > > Your changelog does not exactly explains what _is_ the problem. > > > > If the problem lies in mm layer, it might be time to fix it, instead of > > work around the bug by never triggering it from this particular point, > > which is a safe point where a process is willing to wait a bit. > > > > Memory compaction is either working as intending, or not. > > > > If we enabled it but never run it because it hurts, what is the point > > enabling it ? > > networking is asking for 32KB, and the MM layer is doing what it can to > provide it. Are the gains from getting 32KB contig bigger than the cost > of moving pages around if the MM has to actually go into compaction? > Should we start disk IO to give back 32KB contig? > > I think we want to tell the MM to compact in the background and give > networking 32KB if it happens to have it available. If not, fall back > to smaller allocations without doing anything expensive. Exactly my point. (And I mentioned this about 4 months ago) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org