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 5DF8BC282DE for ; Mon, 10 Mar 2025 12:32:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8BA2280003; Mon, 10 Mar 2025 08:32:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3AC0280002; Mon, 10 Mar 2025 08:32:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B29E7280003; Mon, 10 Mar 2025 08:32:01 -0400 (EDT) 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 95A5F280002 for ; Mon, 10 Mar 2025 08:32:01 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 52D9B80F23 for ; Mon, 10 Mar 2025 12:32:02 +0000 (UTC) X-FDA: 83205578484.23.4A83E1F Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf20.hostedemail.com (Postfix) with ESMTP id 240CE1C002D for ; Mon, 10 Mar 2025 12:31:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.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=1741609917; a=rsa-sha256; cv=none; b=06wK22fstrnABJROHeL6liqmbTCW/uqpjfFECMrOOICuKhKBjTCKQydvUhJpWvfwW3nWYP H2mwBEWP9nCfSoz2ffkCZDQRUIIKxzFLO55FtAXqzPHHxDxX3UwM4L7YBlRcLdGzutzBjo J0L8WqFQBM3WmhuJsLUFbxZruRK7vQc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.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=1741609917; 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=Xd4jNcqLpUY1KCnLHQjwMNQPDUxxOW4HOxcEEEqfTNA=; b=M1LjpQdyWEAR7hwPeIEmFD8Ntya1tyJUhkVYPxNxR6Sx9P8XTKTGarrBkE3xK7eAg7ZANA K3jp/1SdrbawQ1x1x+QCij7slfE75aEKWjTzgRT9evKtjSoKiPpsPaeKiXSvJIe9+JEkwp kOQywTkVesPwN9VjPOHLv8YRHiw6az4= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4ZBGSX4JpGzqVYH; Mon, 10 Mar 2025 20:30:20 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 351CC140361; Mon, 10 Mar 2025 20:31:50 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 10 Mar 2025 20:31:49 +0800 Message-ID: <14170f7f-97d0-40b4-9b07-92e74168e030@huawei.com> Date: Mon, 10 Mar 2025 20:31:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: alloc_pages_bulk: remove assumption of populating only NULL elements To: Gao Xiang , Yunsheng Lin , Dave Chinner CC: Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Chris Mason , Josef Bacik , David Sterba , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Carlos Maiolino , "Darrick J. Wong" , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Trond Myklebust , Anna Schumaker , Chuck Lever , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Luiz Capitulino , Mel Gorman , , , , , , , , , References: <20250228094424.757465-1-linyunsheng@huawei.com> <91fcdfca-3e7b-417c-ab26-7d5e37853431@huawei.com> <625983f8-7e52-4f6c-97bb-629596341181@linux.alibaba.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <625983f8-7e52-4f6c-97bb-629596341181@linux.alibaba.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Queue-Id: 240CE1C002D X-Rspamd-Server: rspam11 X-Stat-Signature: 7u3fk63dpfnqqkkmog6f84tbaofhj41t X-Rspam-User: X-HE-Tag: 1741609915-109796 X-HE-Meta: U2FsdGVkX1+E4MMPjUaMWmCbcX0H0/kwlrx2UlsYe3fxbf8bhvWk0zdXOO2mw5W24m6RP1coVi/iDm12olAZGhsEoR1R8MsRQqu4dh0RbvtXZCXBSuZzMUCJycgjcSgnWjrxoc10iXHEMnhUh3CO4aGGX68WV7V0gHjOt1tLtw7ytFsMt3Bj3qTYd6cDz4M6VYBP3286tYP9gpKEhVpb6vJ7zgODyPDe8Vkmd+UmjyDw33dnJNaILuyZEdTGLUFy2b+NmAsCd/MQi7rlmXhRyXYmrZWofZMLcBPOB3vWtKVdUdA9HcMkf4qKVPk83UoEIr61JqAp62f13nCUUjeHcML1UFTft5VICMEpwxYvST4uN2iJqWfxvFJcL+e2dipgBNS5lVW1/Pjd3RypIlDMWl+tWEbXRS8oATS4Zq3cTgDXrDqB7O1x1ytbyxkfPcCFxqLRcWUM9p8l9ecQRkZTa/o/q0Aj2cfoQauZRvBXlUH39pcJJ5b4kWPyFcwDBN3U2NfPLPBysFvG+S4jViz2Ze6D5hx5bfQvDoLSla9fHjY/CdE7N5w4GFRJjjsbaSZ/+UMnF1imbFcnUVEvzjPCFv1JRgBfqFZX1curAWq5pkv+fSxhyNFjePnyxOISplXlTOyUsrvQUr/2A9XsOMcsfLy3OZcRC9v0VWuLvr7sgJoPKaZ8naGgi29Xdbb3vLyIOy2/DjNuPtT3XNy2/TY5gAX6gbhGbwVak1c9b5E/AIUKA+fNGB8eswdHslwwne7B7Y/zlXrfffoBZPDBoiPj2AI/LLbdKB2UCNPTOXHHxcTSRW3MV0EuiV9Mi64ju/ykjydhzxP3MOt8Ed04hBph95jmWfcvMcSgTaEH2oFMZs9VbnHSIW9rYA9GDc7eCythMaY+jpwcdSuBzAJyE2fEdJytf79u4SDxmkCntd94UOWeDJrQM5cClNaasI3W7/ZVhKnCnCPth61YZrdol4K gLaFJj8n S7U9F+ifVdB5godABavvabpxI3CmqrV4KmWc5dSrwps+eCvrGnZAIrynJphB634YyrwbQ0AIc+bTur1yEjhrnBtcUTCVOCvsSlGTdin+8PBMIMD+fQcnu6p8/0HOcbC3L2mU8uU1mZ5UHEizr5nGzHfLMN2u8v9B53Raw5+pYrOeC9F5HMzeEDPqKsxto9LGnwmlpihuj/3IX2muqUj6LCPGKU2m2xsg4ajLLen9f/0bsLf9b+la32pbNie7KxVNOUxyfAjUIIuoWb3x7RViE61J+mq04D8BPUArxjywD94B+hWQ= 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 2025/3/10 8:32, Gao Xiang wrote: ... >> >> Also, it seems the fstests doesn't support erofs yet? > > erofs is an read-only filesystem, and almost all xfstests > cases is unsuitable for erofs since erofs needs to preset > dataset in advance for runtime testing and only > read-related interfaces are cared: > > You could check erofs-specfic test cases here: > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/log/?h=experimental-tests > > Also the stress test: > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=6fa861e282408f8df9ab1654b77b563444b17ea1 Thanks. > > BTW, I don't like your new interface either, I don't know > why you must insist on this work now that others are > already nak this.  Why do you insist on it so much? If the idea was not making any sense to me and it was nack'ed with clearer reasoning and without any supporting of the idea, I would have stopped working on it. The background I started working at is something like below in the commit log: "As mentioned in [1], it seems odd to check NULL elements in the middle of page bulk allocating, and it seems caller can do a better job of bulk allocating pages into a whole array sequentially without checking NULL elements first before doing the page bulk allocation for most of existing users." "Remove assumption of populating only NULL elements and treat page_array as output parameter like kmem_cache_alloc_bulk(). Remove the above assumption also enable the caller to not zero the array before calling the page bulk allocating API, which has about 1~2 ns performance improvement for the test case of time_bench_page_pool03_slow() for page_pool in a x86 vm system, this reduces some performance impact of fixing the DMA API misuse problem in [2], performance improves from 87.886 ns to 86.429 ns." 1. https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4cd5@huawei.com/ 2. https://lore.kernel.org/all/20250212092552.1779679-1-linyunsheng@huawei.com/ There is no 'must' here, it is just me taking some of my hoppy time and some of my work time trying to make the alloc_pages_bulk API simpler and more efficient here, and I also learnt a lot during that process. Anyway, if there is still any hard nack after all the discussion, it would be good to make it more explicit with a clearer reasoning.