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 EE4AAC47DB3 for ; Fri, 2 Feb 2024 12:26:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F2C86B006E; Fri, 2 Feb 2024 07:26:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A2F36B0071; Fri, 2 Feb 2024 07:26:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 243BE6B0072; Fri, 2 Feb 2024 07:26:28 -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 1198E6B006E for ; Fri, 2 Feb 2024 07:26:28 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D7266805E1 for ; Fri, 2 Feb 2024 12:26:27 +0000 (UTC) X-FDA: 81746786814.15.0841C3F Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf03.hostedemail.com (Postfix) with ESMTP id C03F820010 for ; Fri, 2 Feb 2024 12:26:24 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706876785; 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=bR0bBF9nZ5O0sx5N4YmrWS60aI5sR+0krp5Fe3p9qXk=; b=os2saE6I78sbDeRrgQ3Hat8TL6UESMhc9901oQV4llAtTeXXt8OpAcqDRgDrfOguStv1IC e5NesL+3NJnex4XXfuR5XBQvfBIQt1TDxQClq0ybodKfL3EcRnJOCBg3STPXNJdFVSv4Ny IyXfirc1VWFj3S4BFlu+Nh75N1qR33U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706876785; a=rsa-sha256; cv=none; b=VorQR2+yROhks66D3nqvvtptkBVUJQBmBN3irBi5qE+7BXWkP5j4OS23eiWYl7jFpGjqXR /Sls8sfTz0H0rvuVZ8RZdVjl0AEvPym4uNM6/sk+ZPb1rCVhaJ15qi0Eebta9Xv7L+IzM7 1JfxOcWUD8y7XjEUu845SSWJlRDgZaM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4TRFMH5sspz1Q8XD; Fri, 2 Feb 2024 20:24:27 +0800 (CST) Received: from dggpemm500005.china.huawei.com (unknown [7.185.36.74]) by mail.maildlp.com (Postfix) with ESMTPS id 69B37140384; Fri, 2 Feb 2024 20:26:20 +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 20:26:20 +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> <2e8606b1-81c2-6f3f-622c-607db5e90253@huawei.com> <868b806f0d6b365334ac79a11a3a1a8a1588cbdf.camel@redhat.com> From: Yunsheng Lin Message-ID: <540b1cbf-da9e-eb9e-08ce-39b7f053652c@huawei.com> Date: Fri, 2 Feb 2024 20:26:19 +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: <868b806f0d6b365334ac79a11a3a1a8a1588cbdf.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: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500005.china.huawei.com (7.185.36.74) X-Rspamd-Queue-Id: C03F820010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 997yigu63sxdk4kibwakpedpy4yiqrkr X-HE-Tag: 1706876784-825688 X-HE-Meta: U2FsdGVkX18kS2nxXj8jMYV7wiCBwZXyKfVKkEZ+5ZTIKtTj0N6PvYQDeBhH7pEykGbTWC0BfpdioUpJe1U1xkpI5uDnOa4SD9nW1eHAAcayY6SOGcj+Rk46YQUHdU90qZpDVyzUAuH7H3Akqt3fpxJu7Hk6XvfG9E8g5v0Uob9nLOvOI2c6RNbpk+Q4FWIgUQ6ultUdc+Mh74s8Gwwz25o5cWdvxRmSpfvXyHLQjj3Qjcv647bnUQmkfPIQG/oEqatf4jL4o6czFyG3InuIZKR1v7VT5KedcQWQ3M7eqEDshBk//N7Zx7NdEhwMU/6yk77UwMhXpibguj6BBJYN64MnPxeynavdmDPUCcv+eF+231jKLQfnYEUKCDdp5GDVODbgeB885TGl7w3PN2K1QHfKozuUr2vxK2Z2tIOVHs1iICzLIZJeRB3mBd2RcPrjt5qcmFleW0CcXRyGLzb2K25WnRbtU5LptezqHOK6dRh6J9FgcSSu15PJ+SYkNSm9h+hPw10KbSmixlT9pPZ9pQpWaDJFmhzyGlmhysB47s96nod7BStWkrhdqCx5QtYFqgVS3IBK4gsGAkfEhKBDvg799N7zQfHWGqaWJI4GH7zj33lLHTJMklx1EuMul93eLcRKe6wqhM5CQNS/sGUAx5tblMY4Av5zdWSwDNcSt5LZzj4GHlBeJVLbxAtY0LHyGCLP8QnRp5HIuFYsotEWLjFESpn1lg8ud/Qx0xRcGM3ZMjjaVZ0GabAtCTVX3W1jfOITcRdAuJJAkImEUU8FCDk8SFUulbz1uJ1C7rmYTvRqoSsSRX+A8SXNquCfJlAw2RnTM1GdvE/YeSaeIXL6Uz9lINziY0xx7wLAlpuSFmCWXuCuc3b4DHvaH5Y1UqFtGkejHmfnPezHaKfBepj81805wxa3COak2ihfQPLgvJwq1BGw4BaYj75cQ1+WN9IzmWlnU6yf1uJ9fwfQWdx FWyumAEh pBI+/0oRNktx4S3br2cf7kI93IfXI9YfAyyj1oX6eArZi95w1sxZ0yf07cvOr8eZwnB9EJR+Gn/VcmmlTD63b59PJlJO2gKQ47TROanHUGVzMCZNvDBof0A//A9wb+albgPTCNKidGIh7asC/YnWn50O6yEb5wq4L7BWqZ/l86oWcYMrzXfbRdIcO8SqsZxuXAvLjCDEiLPneyQTz/XVsMipD6ZGhqy+dtzRQsMLHtcfyQmRB7r8+mZDdfQ== 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/2 16:36, Paolo Abeni wrote: > On Fri, 2024-02-02 at 10:10 +0800, Yunsheng Lin wrote: >> On 2024/2/1 21:16, Paolo Abeni wrote: >> >>> 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. > > You are right! I got fooled misreading 'gfp' as 'gfp_mask' in there. > >>> 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. >> > > I still think/fear that behaviours changes here could have > subtle/negative side effects - even if I agree the change looks safe. > > I think the series without this patch would still achieve its goals and > would be much more uncontroversial. What about move this patch as a > standalone follow-up? Fair enough, will remove that for now. > > Thanks! > > Paolo > > . >