From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80F57C3DA6E for ; Fri, 5 Jan 2024 15:35:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFB3F6B02E5; Fri, 5 Jan 2024 10:35:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EABC96B02E7; Fri, 5 Jan 2024 10:35:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4D496B02E8; Fri, 5 Jan 2024 10:35:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BF3896B02E5 for ; Fri, 5 Jan 2024 10:35:39 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9592A120313 for ; Fri, 5 Jan 2024 15:35:39 +0000 (UTC) X-FDA: 81645657198.06.3E7CBC6 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf20.hostedemail.com (Postfix) with ESMTP id B7A021C002C for ; Fri, 5 Jan 2024 15:35:37 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HxubLk51; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704468937; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LuFOrc8jZyA8aQFwg5Wcmjhl91YFITaxwbTd5b7XYqA=; b=gsXIOeYcbQbYSnYsE7RCzhuHWCw1S5rrESYX23Lms1rOeusBNqIeG7+rto/jlDvxqyBt/J 8ybtwLh+5SnEysHdjqQQTXguGlax5kvYxiwzizsUFdm6UB0fCqiUZzEK4+fgCpiMT9Te31 Ye+GjmpHmSRe1WV/ivhzqulh5NTCzXE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HxubLk51; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704468937; a=rsa-sha256; cv=none; b=jNqr2rDge5IAVzFlghSmLRpO/d28x7hNgJKOfJraGUgjhPvR8nM1OakBiICz0sIKHFJHGn UfwYqVrOV80CNDeJyjX+mV6Lu+jCH1SqeQfChSAHXVxt4Aay1vwExwT6vnc3BiCeyoY9pq JcE3gM5wQBstCYQBjsNeaUNsD9wDMoQ= Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-6d9a795cffbso492009b3a.0 for ; Fri, 05 Jan 2024 07:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704468936; x=1705073736; darn=kvack.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=LuFOrc8jZyA8aQFwg5Wcmjhl91YFITaxwbTd5b7XYqA=; b=HxubLk51yMmbPbKAsB3WIkZXzkILw5ub28oeL6/BNSJJm9wOAAHz/399edDWmWvy88 GUl/7W/kVI9TSFUAw/yzAWjKBFMuN1Q6zaTO6HUVfhvv8cgitYB6uWPjAaUukC5F9/w6 uG4zFfBrhr/NO9vXul8DT80qj6QtaX71EBBpT7NoQKaH6d+w1+n+xZjj5klsYlbkPicN LQI724TiQ6yD3kQ0GYmuMsn9+b+QJ+Fz3WbDb2pSMlhjEOQ2xPWTk7+++d6/k53bp52l HEqRqxTAZLiu7vCME6oFgKOBkizQER1oPbGqI3D3ZQlCFU/bg3oKj+MuGEmt3QeqPOHM IlGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704468936; x=1705073736; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LuFOrc8jZyA8aQFwg5Wcmjhl91YFITaxwbTd5b7XYqA=; b=Rk/q/a55YzRa1jD1SJjBzjcATNtwUsV7rP6Im2FQiSRrQrXlHumMGQXDsPYZPrDojH wJ7MRwYvVQGMitLwSPgr6GpYZ9Z92+9O/A6apR35ofl8MObXNrzib1FbskMV8FKmGpRy Ps+2dpoAhgX9eKDphSmnSNG1hWuGWIDELU0ujiLxChmfR/DrOtycxT3n9FsBqT+Q5hf/ I6tPs0u7PL7vTmiKo7Ism9lK42hHfKHRvBQTzXZvG1kfIFMR5pVJt8BB5Mqxr/M+lVNI r3iVpMvLPafkK9rosx+TvAprviHWcsZKJclvp5zHg91Llz4IWRkwKNl75jL1zS/Cb3zk vomw== X-Gm-Message-State: AOJu0YzyXtUD7k2QvZszwpuTKlKVyvgL66ygHvPIxffI8/RnOE/E+6N1 t3LUz4ClRfsi2YuHM9yN2zfND7+n9MI= X-Google-Smtp-Source: AGHT+IFf2OUiRiGgAY55SA0vjlNzy0JLVutkSWgDpb2/cc/7tt9nx67tojGCFEf8ku5WoiKMgNtQWw== X-Received: by 2002:a62:5346:0:b0:6d9:b8fe:eee7 with SMTP id h67-20020a625346000000b006d9b8feeee7mr2864351pfb.8.1704468936510; Fri, 05 Jan 2024 07:35:36 -0800 (PST) Received: from ?IPv6:2605:59c8:448:b800:82ee:73ff:fe41:9a02? ([2605:59c8:448:b800:82ee:73ff:fe41:9a02]) by smtp.googlemail.com with ESMTPSA id l3-20020a62be03000000b006da13e27904sm1530638pff.44.2024.01.05.07.35.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 07:35:35 -0800 (PST) Message-ID: Subject: Re: [PATCH net-next 2/6] page_frag: unify gfp bits for order 3 page allocation From: Alexander H Duyck To: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Michael S. Tsirkin" , Jason Wang , Andrew Morton , Eric Dumazet , kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-mm@kvack.org Date: Fri, 05 Jan 2024 07:35:34 -0800 In-Reply-To: <20240103095650.25769-3-linyunsheng@huawei.com> References: <20240103095650.25769-1-linyunsheng@huawei.com> <20240103095650.25769-3-linyunsheng@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: 9jx9b9derd4tqjii67365zba4ha56j9e X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B7A021C002C X-HE-Tag: 1704468937-637023 X-HE-Meta: U2FsdGVkX1/z+gOOAP93fybFgzZ9KNjNCKLTpcYJ+YYlsZEsgCChmXL9P/TrG1Q8ronvv7shnqJ+Zo4aadNsbt6LEqFHgTFQd4QcNgeSnd2O8zCOLSN2ir3kgOyc7zhGLjgVRQ0uUvBuh4tFHXK55aohdue0vSqncZMc9VK8UQRz732RDh52I7j6GgfZELOA9BHktC7zuKiTg2ZCWyco2sj5YIU15d9lRGqPtR7cRl4YedwadHuuCwCkf50gXFLy+8uiOabmB1M/YCjF5wc5yjj6P5BiNRUoHzbE6AUFXjJPQVmQS22qIwjciGQ3jDpgEH5QpcCtUpX8acqR/4v3x0IJXOwWaDHaxAcyGEphri4guamEEnTvALAij5KcDJ03ozbVTx00NxqPPFSCs7h1E579rSQ+AZ1yDw5HPR6AwvtGjYIDmTVFwgDflI37unaxISeBkQ+/W1OD2aZ3ut9ZftGFWBSY6lPCAuLopF1z2ACwWExKa14SjZldDt0EIQcN2vtkqtyJxwMygS4PZueb71gfSeUtc5D5pon0gCK/0GgwLC5XgqE8gWXfyLXin/JCH8HkQKnYQivyxhV8EExC5DjClUT00g/G8rVnK78iN0SQ8evwJUfkEVNbtQkiwYJZm2HB3iS7LQz9+qR+ZdJ/+y/3VSIBbUAEI/4XS0YRatVj9cftfEUFD7n061Vv4U6l8XDFi53dotSKXB6RXXpadj+4PeXOy2JAVgZ9v2zh7zXgaTK9RN85wWrzup6VHkwq0FYKE41AGf1c3Kg8Chiv72QcGY4FMopR4xmdsLr+qSEuF5BpexysnGVM0LD7CC3zLy4A9mxNoq7hG/hAXap0fm/U/b50BrWZMMkga262UK/f/r16OvZUulg3vFvx7KzQdLqH85wM1bkKvyWKxXNco4liB53HLPL02BUpSngM8VdnA5ZlDVZ0rBFigA1u9KrQIF9fdzgJ0I5+pvAbJQX 75aJzxOG JYrIoVaVQ/0SRio+XCHzNBa4WsjVB0xryn8Dgyjucc/dgQIejkyJ8GY7wMn+bcAqbmMngimSKP93lW15Hwnv1TgoryqeHhnNMs5NZKCpYBjtF0UHClt5oZUA0yLN7a0WnhhSgQpMYaDelCs4VeHMUegV20AjItENmGEzkS58PighV1/xBErcFqFDuN297N4LgdZxqUOgvco6wlsvcPy41uFCD9kk5m4gtT9xFuyOGFx2K+cZw+U1gNuIDYsahhnwlSe968Z49iEJodhMwNbWZnpDweK1/+R/cTokubWoc6CGiDAkPDTVSs2ref01YkarB3jjWP9JlugNJhScukHP9sI/hly73XJxd8u71Vq7VGcBNRH7dqeYjre4ZOOr28xY8R8yJbwgO5UqcsNYOl5PYnlV66HieIMNA8pEN0GXX48JuVEaxT5T2ECvrfzDJRLLw2dkNTWYLZNSOxj7Vk6C6Gbp/lZClHwXmDewFwQM0kpKzkDFn3oMhZ5k8xr0JbjEraG31dDV9UrzVt5/YIzCBZDREpLkx09BKWqipbaMECC84yJrqO9FL3CI5ssXR1ADfhT+BR0NhvDWwSTAVxeFE1E4QduYlCqmBpE/9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 2024-01-03 at 17:56 +0800, Yunsheng Lin wrote: > Currently there seems to be three page frag implementions > which all try to allocate order 3 page, if that fails, it > then fail back to allocate order 0 page, and each of them > all allow order 3 page allocation to fail under certain > condition by using specific gfp bits. >=20 > The gfp bits for order 3 page allocation are different > between different implementation, __GFP_NOMEMALLOC is > or'd to forbid access to emergency reserves memory for > __page_frag_cache_refill(), but it is not or'd in other > implementions, __GFP_DIRECT_RECLAIM is masked off to avoid > direct reclaim in skb_page_frag_refill(), but it is not > masked off in __page_frag_cache_refill(). >=20 > This patch unifies the gfp bits used between different > implementions by or'ing __GFP_NOMEMALLOC and masking off > __GFP_DIRECT_RECLAIM for order 3 page allocation to avoid > possible pressure for mm. >=20 > Signed-off-by: Yunsheng Lin > CC: Alexander Duyck > --- > drivers/vhost/net.c | 2 +- > mm/page_alloc.c | 4 ++-- > net/core/sock.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) >=20 > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index f2ed7167c848..e574e21cc0ca 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -670,7 +670,7 @@ static bool vhost_net_page_frag_refill(struct vhost_n= et *net, unsigned int sz, > /* Avoid direct reclaim but allow kswapd to wake */ > pfrag->page =3D alloc_pages((gfp & ~__GFP_DIRECT_RECLAIM) | > __GFP_COMP | __GFP_NOWARN | > - __GFP_NORETRY, > + __GFP_NORETRY | __GFP_NOMEMALLOC, > SKB_FRAG_PAGE_ORDER); > if (likely(pfrag->page)) { > pfrag->size =3D PAGE_SIZE << SKB_FRAG_PAGE_ORDER; > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 9a16305cf985..1f0b36dd81b5 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4693,8 +4693,8 @@ static struct page *__page_frag_cache_refill(struct= page_frag_cache *nc, > gfp_t gfp =3D gfp_mask; > =20 > #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > - gfp_mask |=3D __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY | > - __GFP_NOMEMALLOC; > + gfp_mask =3D (gfp_mask & ~__GFP_DIRECT_RECLAIM) | __GFP_COMP | > + __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; > page =3D alloc_pages_node(NUMA_NO_NODE, gfp_mask, > PAGE_FRAG_CACHE_MAX_ORDER); > nc->size =3D page ? PAGE_FRAG_CACHE_MAX_SIZE : PAGE_SIZE; > diff --git a/net/core/sock.c b/net/core/sock.c > index 446e945f736b..d643332c3ee5 100644 > --- a/net/core/sock.c > +++ b/net/core/sock.c > @@ -2900,7 +2900,7 @@ bool skb_page_frag_refill(unsigned int sz, struct p= age_frag *pfrag, gfp_t gfp) > /* Avoid direct reclaim but allow kswapd to wake */ > pfrag->page =3D alloc_pages((gfp & ~__GFP_DIRECT_RECLAIM) | > __GFP_COMP | __GFP_NOWARN | > - __GFP_NORETRY, > + __GFP_NORETRY | __GFP_NOMEMALLOC, > SKB_FRAG_PAGE_ORDER); > if (likely(pfrag->page)) { > pfrag->size =3D PAGE_SIZE << SKB_FRAG_PAGE_ORDER; Looks fine to me. One thing you may want to consider would be to place this all in an inline function that could just consolidate all the code. Reviewed-by: Alexander Duyck