Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1591695ybk; Sat, 16 May 2020 16:41:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxr/u+kTpYP3y7Sqs0EybGXqH1Fw3nsxDnxvSBw2bf96KX0LYTT1kn4ifxW2Yb+GnEmhXMQ X-Received: by 2002:a50:eb8e:: with SMTP id y14mr8129555edr.270.1589672478457; Sat, 16 May 2020 16:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589672478; cv=none; d=google.com; s=arc-20160816; b=DEpL8MDetjlT8qXSmAF7disBzhCfvPnpe+kG//6vMFJXVIdod2y2zyDSCGr2X8Jt+U 9UWf9juMYxiiCsItrUfn35MvRzJlGeAUosjI3E0BaDY/QqAQ4rTRXREESZEFcTeQbuE8 7lT8+CijdbWOnGE3hmLxS5/4Mk+0hQhbfWcSayWVAB+gN9jH+WR++L1Z7A2+t3//X7xZ E9U3mWMQ8JIefDBA8Z1rB0hGAEjXMp39+fJnxY5bP29KDtFuFRkcD3n6KA9EwkpCMya0 TjOpk/ZV+b5IyAB5hVerSOG0+GzkGK4AY3qsEDf2xv04UC/UFWsVeEj814BcZkp1FdXF Uk7w== 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=KxEo8hwVJlUHZX5ktzNGr7cWyX9V787+uityKk0JCNs=; b=d3dzKUi51UcSKXqHx44Y2Gm53zU1wBFh6AhU1UPPeelS4Egw8pDzQGdHZQ4xO6u1uz QIozjVlQN68U91vTC+HGIEv8H17MParWBRgzejmnlzZxR6lAKaJTUnvmJnuLUPmkqzhe hmlAdDTHxyqkebP1JOJfMOWNDVRgC3MPpw9bJSnId5tYUuflsE1ohgZHmJsvNcNhAP6v z7e5v14dL1w6NLtEkwgtYU3OGlHWwMB4y+WhzGSnZ/BjpJq1t0W8HzMlAqUrMDjvt81i FdXvv80ap8B9k0UzWqc9spKqfHKUVguJCYsjxzNWyw1ZKyYR3RVJLzbGjIZ4HSG83zUL zRfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id re19si3716001ejb.56.2020.05.16.16.40.53; Sat, 16 May 2020 16:41:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726833AbgEPXjc (ORCPT + 99 others); Sat, 16 May 2020 19:39:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726729AbgEPXjc (ORCPT ); Sat, 16 May 2020 19:39:32 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0042C061A0C; Sat, 16 May 2020 16:39:31 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (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 0E03E126390CD; Sat, 16 May 2020 16:39:30 -0700 (PDT) Date: Sat, 16 May 2020 16:39:27 -0700 (PDT) Message-Id: <20200516.163927.1112911965183377217.davem@davemloft.net> To: shakeelb@google.com Cc: edumazet@google.com, willemb@google.com, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page From: David Miller In-Reply-To: References: <20200516021736.226222-1-shakeelb@google.com> <20200516.134018.1760282800329273820.davem@davemloft.net> X-Mailer: Mew version 6.8 on Emacs 26.3 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]); Sat, 16 May 2020 16:39:30 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Shakeel Butt Date: Sat, 16 May 2020 15:35:46 -0700 > So, my argument is if non-zero order vzalloc has failed (allocations > internal to vzalloc, including virtual mapping allocation and page > table allocations, are order 0 and use GFP_KERNEL i.e. triggering > reclaim and oom-killer) then the next non-zero order page allocation > has very low chance of succeeding. Also not true. Page table allocation strategies and limits vary by architecture, they may even need virtual mappings themselves. So they can fail in situations where a non-zero GFP_KERNEL page allocator allocation would succeed.