Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1091248imu; Fri, 4 Jan 2019 12:55:44 -0800 (PST) X-Google-Smtp-Source: AFSGD/V7kD4ME+k5QHIbJ3SbmMn3rkHmoyA2z4nBBHqRd+oiv0yWa9C7UxO10m4AUmCa1C0waH74 X-Received: by 2002:a62:5ec5:: with SMTP id s188mr52831373pfb.145.1546635343993; Fri, 04 Jan 2019 12:55:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546635343; cv=none; d=google.com; s=arc-20160816; b=dEGjVt5IBi3CRKv2K8/HYE53RBeYsVEX1WmV7uRN1igWb+nd8pkZXdU1aeRM1+fCBn RL5yyYdq+tPR06pBpFCJ6W5sv7aMZGGejTS3iPK5yWp1TlP/JTd0gDMD9Qkg+60jKbi8 9cGARjQBVIc6vK2n2ekEUwP2cU9xAeTZDI6VfhIbegGld8NQRJrjFowI3/N9o+g/jaR9 V52Hlydk9fj8Qij2NT2JrIu4eo373y/AApEr11zHCHg3u+74NS16fLgHPkxJnhgKYre8 rLOh4dUgWJhESnXDHwn8pTg0LW3A8snuDeIsGX9ekOZNnMCqOjyyw+6olyX0EKEk3De7 9IQw== 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:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=ZiMV5CkRvSKZ8bcrKnzoWRSE6fAwYX8SMg9IdIY1kZ0=; b=m9RgpTkub1h+lLy9Bi5XefGG36OeEahOFTvsnKW2g3nBWXInz5CteTiUniqDBoTkXz VhMaWlVo/IjF4lC8Kz57BAYA0MlTwr2Z5lQCmxb8oOM3O7BnlsvVrZO5ylzAjNwDw8uU nLJCUKB1RRf8worGkSMZ3yWaKaudPB3YhNWGQH6yWAxxYtrqPJ7xklhQWpWA5LNPwiZ0 0qPdhRYhrON0AHPcEhJHKPqrkrOTC7W7zNZoAEQej1K0JQWdjkA/MqkW9NDstHfQ3pgj zwTTMIt6E0kNJaXuztcsjFfqHgyaZlgs2LBMeVaGvwpskIuLaPEopFW02qm4XHUXmVzB HXGA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s123si12011812pfb.274.2019.01.04.12.55.27; Fri, 04 Jan 2019 12:55:43 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726118AbfADUyQ (ORCPT + 99 others); Fri, 4 Jan 2019 15:54:16 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:48602 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725987AbfADUyP (ORCPT ); Fri, 4 Jan 2019 15:54:15 -0500 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::cf9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 160EE14C5C7FE; Fri, 4 Jan 2019 12:54:15 -0800 (PST) Date: Fri, 04 Jan 2019 12:54:14 -0800 (PST) Message-Id: <20190104.125414.2212636411296708605.davem@davemloft.net> To: rientjes@google.com Cc: edumazet@google.com, akpm@linux-foundation.org, willemb@google.com, mhocko@suse.com, vbabka@suse.cz, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch] net, skbuff: do not prefer skb allocation fails early From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 04 Jan 2019 12:54:15 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Rientjes Date: Wed, 2 Jan 2019 13:01:43 -0800 (PST) > Commit dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by > __GFP_RETRY_MAYFAIL with more useful semantic") replaced __GFP_REPEAT in > alloc_skb_with_frags() with __GFP_RETRY_MAYFAIL when the allocation may > directly reclaim. > > The previous behavior would require reclaim up to 1 << order pages for > skb aligned header_len of order > PAGE_ALLOC_COSTLY_ORDER before failing, > otherwise the allocations in alloc_skb() would loop in the page allocator > looking for memory. __GFP_RETRY_MAYFAIL makes both allocations failable > under memory pressure, including for the HEAD allocation. > > This can cause, among many other things, write() to fail with ENOTCONN > during RPC when under memory pressure. > > These allocations should succeed as they did previous to dcda9b04713c > even if it requires calling the oom killer and additional looping in the > page allocator to find memory. There is no way to specify the previous > behavior of __GFP_REPEAT, but it's unlikely to be necessary since the > previous behavior only guaranteed that 1 << order pages would be reclaimed > before failing for order > PAGE_ALLOC_COSTLY_ORDER. That reclaim is not > guaranteed to be contiguous memory, so repeating for such large orders is > usually not beneficial. > > Removing the setting of __GFP_RETRY_MAYFAIL to restore the previous > behavior, specifically not allowing alloc_skb() to fail for small orders > and oom kill if necessary rather than allowing RPCs to fail. > > Fixes: dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by > __GFP_RETRY_MAYFAIL with more useful semantic") > Signed-off-by: David Rientjes Applied and queued up for -stable.