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 DB06AC48286 for ; Fri, 2 Feb 2024 02:10:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 136986B006E; Thu, 1 Feb 2024 21:10:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E72B6B0071; Thu, 1 Feb 2024 21:10:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF17D6B0072; Thu, 1 Feb 2024 21:10:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DBE576B006E for ; Thu, 1 Feb 2024 21:10:12 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 61979140DD2 for ; Fri, 2 Feb 2024 02:10:12 +0000 (UTC) X-FDA: 81745233864.13.DCB600C Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf22.hostedemail.com (Postfix) with ESMTP id 3B6E8C0017 for ; Fri, 2 Feb 2024 02:10:08 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706839810; 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; bh=vvu3GCmDyq9TWpsngesEYRVOG52JlODUVPa7l8IRL10=; b=5z6nowUqvGe7pIQ85Gq9ZUBlKilghFNg0X99sz0OcuZzP9kVu+8mTnogQNe/XZss6Rp1qF F1T3LneOJ5Yowu4AHcYYYZs/08mCkC8Kvttcsc9/LvOkmlMMppSYtOAslGg6jkg/OZ/DfO Xt6jLSoMyOQOy1TDCo2Qr4uCjTz/Png= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706839810; a=rsa-sha256; cv=none; b=2DeLNB2Z6mD+ctP+lyyol7VTOCKTkw6OhP19dFJ462BpqFXZBECAgrF02KVeBttXf7e4Hj lVIZy02Llcntvf20Hk8Dx9WtX1EH/vCpl1tHH3xNNrCEKHvSJ35Jygx8EHLJiVcLik50M4 eqcdrgvmG1mJ/95aj+w1S4GTi/r4cgU= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4TQzhj4yq1zXgvp; Fri, 2 Feb 2024 10:08:37 +0800 (CST) Received: from dggpemm500005.china.huawei.com (unknown [7.185.36.74]) by mail.maildlp.com (Postfix) with ESMTPS id 0296B18007A; Fri, 2 Feb 2024 10:10:03 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 2 Feb 2024 10:10:02 +0800 Subject: Re: [PATCH net-next v4 2/5] page_frag: unify gfp bits for order 3 page allocation To: Paolo Abeni , , CC: , , Alexander Duyck , Alexander Duyck , "Michael S. Tsirkin" , Jason Wang , Andrew Morton , Eric Dumazet , , , References: <20240130113710.34511-1-linyunsheng@huawei.com> <20240130113710.34511-3-linyunsheng@huawei.com> <81c37127dda0f2f69a019d67d4420f62c995ee7f.camel@redhat.com> From: Yunsheng Lin Message-ID: <2e8606b1-81c2-6f3f-622c-607db5e90253@huawei.com> Date: Fri, 2 Feb 2024 10:10:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <81c37127dda0f2f69a019d67d4420f62c995ee7f.camel@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500005.china.huawei.com (7.185.36.74) X-Rspamd-Queue-Id: 3B6E8C0017 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gbpsbsb1pqp4cpjmkmcg9r9ckbr398uq X-HE-Tag: 1706839808-486621 X-HE-Meta: U2FsdGVkX1/NfOEA+ZEFZZRFRFEuU23idf/vVQb27CBjhTXGoUVu6o27vORPf6gm8DV1aq1yB5iRm3h1/5B/3g1Hb380VocGfkTxQO16vtWVlHwF1BRvkkgOV3QqeMjLwn/zhpawccwmwp/Vb1QqaHsWNQtPdcUFq//IP1GJy8FbmR8I4zWSrOHoefq23CLOx3In7sPKTwWylpv7y2wNiQQ7ec/NRkkeeZ3BVv/Oyw4tNiSBK2ot5OHBm2pdmtMU/vCTmrcG5TznYVfmbXkO72EYWa0JJtMAucrCashTytmaQMAyGCw7Tm4ArXH3sQkMUaDs1BuhHtDdguzoHs9T1g1sD284J7w/Ki5I+EVP4De8y43NGqIkLfQYxvR2oLhkScw4DCQfQyOzWQyBigwbiYjj3QnfNnV8QDpzXHttqp5SiI58JSLqUszvK5EG4WQDQp9anHzE9YNTx1Q+FUAK6mZbsp1RQSV3NcMlDUP7mF8sTpLdLle434xWQXG1h2Fge1b2A6Iw1IePDmhbO1L8tAOBKnBGJbL+eZKWuSPRXk1JVNPWUSIiY8RvmGHQwn02EANIheEzQgwnsF27wGLJX4xy42Tu/bkllX0S8syc3447BQLnX6pp3cfOJDofThFbI0/yhCPP+WAniekffAbt9nhWdnIlmeCOC4XeoGV9zNX+y7vSmLsvboBQSPNEBigQVVxmUExEIJY1A51yac+7sVjbz1hp6y3T4Ut88DdyQ9gjgP+zg6dMQP8VDKsmgCMpU7qjzM/jaB0IOIV5z+cNOKWRmzV2tpyyqOVJD1prQG7ZwFCERAfKu4Fhxbow4vryWzytZPYw6795biag7bNNYA/atiZgzhUfh6/ClMiRXxzy7W1qmWB5QCQ1aJlDVS924afRqP7w+raHD7Rq3JUNyzgLRRoBnrJt8cz5DxExWT4DAUBk/vowOSspzRhFmZmecfM8mdgp4KJCsPaHrxQ q4/WWsvO /sDV6xLsC59wsVCkkGPLZqoBmBtJ2WQbkL40ZzgX2A1X3z1nESSPyyHlj4G5oAHpCQ84fhORVkX0GxLbOm5b/Vbs6tOc7WLr79/WlStiBnlK6PdS8FLVF8E9DWTqpeVxWE8fz8FhFmXa+SofDyJ4glSG7jaaH7l1IwMlwZYKKoL3XAEQL5VXWQLMidan6QvxyD8BDDxaN83QhiXc8F+2GW/1/iWLzne8fXP2cN5lEERFl6HKEHWKcLjxv/WV5P+q4IbWu1iVghfOXjOwG3Ytu7aKeTcV1HgBogQPRYfnkkxgwuOoAfUw8IcEHztbR1kth0/nJ/sbFGootT2WIjlygDyQ1ICgLbR2JYFr876vvhRuYl3k= 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 2024/2/1 21:16, Paolo Abeni wrote: > On Tue, 2024-01-30 at 19:37 +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. >> >> 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(). >> >> 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. >> >> Signed-off-by: Yunsheng Lin >> Reviewed-by: Alexander Duyck >> 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(-) >> >> 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_net *net, unsigned int sz, >> /* Avoid direct reclaim but allow kswapd to wake */ >> pfrag->page = 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 = PAGE_SIZE << SKB_FRAG_PAGE_ORDER; >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index c0f7e67c4250..636145c29f70 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -4685,8 +4685,8 @@ static struct page *__page_frag_cache_refill(struct page_frag_cache *nc, >> gfp_t gfp = gfp_mask; >> >> #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) >> - gfp_mask |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY | >> - __GFP_NOMEMALLOC; >> + gfp_mask = (gfp_mask & ~__GFP_DIRECT_RECLAIM) | __GFP_COMP | >> + __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; >> page = alloc_pages_node(NUMA_NO_NODE, gfp_mask, >> PAGE_FRAG_CACHE_MAX_ORDER); >> nc->size = page ? PAGE_FRAG_CACHE_MAX_SIZE : PAGE_SIZE; >> diff --git a/net/core/sock.c b/net/core/sock.c >> index 88bf810394a5..8289a3d8c375 100644 >> --- a/net/core/sock.c >> +++ b/net/core/sock.c >> @@ -2919,7 +2919,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t gfp) >> /* Avoid direct reclaim but allow kswapd to wake */ >> pfrag->page = alloc_pages((gfp & ~__GFP_DIRECT_RECLAIM) | >> __GFP_COMP | __GFP_NOWARN | >> - __GFP_NORETRY, >> + __GFP_NORETRY | __GFP_NOMEMALLOC, >> SKB_FRAG_PAGE_ORDER); > > This will prevent memory reserve usage when allocating order 3 pages, > but not when allocating a single page as a fallback. Still different More accurately, the above ensures memory reserve is always not used for order 3 pages, whether memory reserve is used for order 0 pages depending on original 'gfp' flags, if 'gfp' does not have __GFP_NOMEMALLOC bit set, memory reserve may still be used for order 0 pages. > from the __page_frag_cache_refill() allocator - which never accesses > the memory reserves. I am not really sure I understand the above commemt. The semantic is the same as skb_page_frag_refill() as explained above as my understanding. Note that __page_frag_cache_refill() use 'gfp_mask' for allocating order 3 pages and use the original 'gfp' for allocating order 0 pages. > > I'm unsure we want to propagate the __page_frag_cache_refill behavior > here, the current behavior could be required by some systems. > > It looks like this series still leave the skb_page_frag_refill() > allocator alone, what about dropping this chunk, too? As explained above, I would prefer to keep it as it is as it seems to be quite obvious that we can avoid possible pressure for mm by not using memory reserve for order 3 pages as we have the fallback for order 0 pages. Please let me know if there is anything obvious I missed. > > Thanks! > > Paolo > > > . >