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 376AAC282DE for ; Mon, 10 Mar 2025 12:59:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6CAF280003; Mon, 10 Mar 2025 08:59:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1C12280001; Mon, 10 Mar 2025 08:59:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E454280003; Mon, 10 Mar 2025 08:59:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 81B59280001 for ; Mon, 10 Mar 2025 08:59:56 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0E24C160F42 for ; Mon, 10 Mar 2025 12:59:58 +0000 (UTC) X-FDA: 83205648876.23.FCA20F2 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf13.hostedemail.com (Postfix) with ESMTP id 6E64220005 for ; Mon, 10 Mar 2025 12:59:54 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=nA+4lbcZ; spf=pass (imf13.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741611595; 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=RBXViRbgYvu9SyQX3LTahN7Wc3wvAYaCUKId9eKui+E=; b=1LjNnkckZPCMrQQTs0jAtthRcDDorYjZFuZLnh+SSVQ0jLK1jJs/kS3BFN/tnNtjgw1iSO cgNyL5XvnvwQuITUaOlE/TuZ0wsi6h/2MxKSLJJLCYb3M0hlJtHtGUCjmiyAYYOB8k5Fg/ ckGi4dqFCUTAs8I1bDUqo5dROGqxvhQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=nA+4lbcZ; spf=pass (imf13.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741611595; a=rsa-sha256; cv=none; b=RocedpJygNkD6fIRklrOtQIvdP0Cm5d4mKKFrgm1Ijv2ktpNQwCyaYMKCL1Rq7a04DhPnH QkZhPUQ4wlR0+TVJ0GT3I86cnW3Z/2moEU28GOg5kyb61TUNHxQMRtwtURbTquBsOUI8aM 3EUtoyiBY97LBt5BnqgGGeB7+tEWEDs= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1741611590; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=RBXViRbgYvu9SyQX3LTahN7Wc3wvAYaCUKId9eKui+E=; b=nA+4lbcZa6zBlirYk6vuMbOh8gNs1V2LDvNYx4kgX1uAYEaQaaNzhNE/GlcLeLi8sMuIOklgWTrFeFxa/uwkjbZIG/C3JZQZY98oi5f50YbX1RNuX5XHIyJ5UobTAu2bf9kdGdFozGo5iLW3rClsz4DMUyGxVKE/63FG2AcLe8E= Received: from 30.74.129.235(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WR3.NYS_1741611585 cluster:ay36) by smtp.aliyun-inc.com; Mon, 10 Mar 2025 20:59:46 +0800 Message-ID: <316d62c1-0e56-4b11-aacf-86235fba808d@linux.alibaba.com> Date: Mon, 10 Mar 2025 20:59:45 +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: Yunsheng Lin , 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 , kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-nfs@vger.kernel.org References: <20250228094424.757465-1-linyunsheng@huawei.com> <91fcdfca-3e7b-417c-ab26-7d5e37853431@huawei.com> <625983f8-7e52-4f6c-97bb-629596341181@linux.alibaba.com> <14170f7f-97d0-40b4-9b07-92e74168e030@huawei.com> From: Gao Xiang In-Reply-To: <14170f7f-97d0-40b4-9b07-92e74168e030@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 6E64220005 X-Rspamd-Server: rspam03 X-Stat-Signature: utxiiiaxfquftiw1t7irji7akkjebqrt X-HE-Tag: 1741611594-250675 X-HE-Meta: U2FsdGVkX1/xJflNdTzhyFXAYBIDtJW6/Mvm/FpK6zPRkp1zd3vzjbSYYSAaPZwZ3hqTQgFjid8iIXXNELqFrbXjM51hkkX63ePf7cPx/Sc5C+2ixxCdyWasN8GnRlOjuS0WzPYQh5aAb+blrp8PothD3/BEnb/ZFikCarz1wU+ZAzSRYgEUkhSCiMzC1FsysD4hfnDPm43QQUNK8O0NFl1kNFxPcBPQb8V3tOamkpkztY9PifnZ5ovT0c6D1fWKW1yMUYIdWtngocQBgu/e1i1tH9iRDxwkmhAPKuvGnXxuNPOMl3voKjhfC2LOua5KktGvOWuihPiWECbjr6crcvNTIHsLaQiGqQ+ZCiqTAmLRqe2NcPNAnyk3LqUYVtxa7eTeeYGzrvxHt7k3xPB0GxgOHNTk+ZF5egY8GEiMgJ5l20GHLuFvf5W7ZrBrj2Rh/HLOq/TlKZHDdP4ATZQHdTzVz13l0YiBvtLQn8Jw2SlrGa1t3+FABuKVieHuL8kPIpGvoEOlHD6xOa8zlKE8bTQl948ilSM/M44XQuqi+wBSM+WbxlIY2BetfOfaINq7HsoBZ10ErIHAOK1OzV7AHS8Y1FE70VZO45VQKF2z+FOaIhARQq6JXRHh1UVI2Kk/Tst/TyngNyM/xYxQhHpo9E1na44jhtMM0gcxSq/RJpgRP+UUyPvJ4L4DV1kIrgsaQUfhaEBaz7FFk1ZX4qBwxzYNzLi4yZjKHbcNjFhIiQUOGKKyQhpCl6kSJNQMnjnb43/X5E8tSlEF6rwv09AB6PJoFw9e0ScDFaH3zWidMGMBRQipWEYZTjiJt/xscTr2SXfaI4qR8q81Xje1bO1mxDIrOz7I8CqajHxKq8IZtidKcdm+dIlaKO86VS745madV7HoJoc8GstTQf0NAiLjWPnECEqj+/tYD2zrBMOPfjFWvW7j4HNkurNzlb8vZlstwR/UhsDLJtHrtdf6ok0 bpCDAc2R deGgcBOfzSI7XF3zwoM0s87t93bLaOz3Ib7YVnMaOla5VBzKCx1J+HAMNlDWSIa3rkJ894F9zO2SqKOufB2wqI01hPOuoMJa0MAkt+weXeYy7fxqV03i2mzZir2AWdET/Hr8fF66cE2mnLspK8Z9ycI6p5NSn10UComxrFlAD4zPtYpyHe7NxEddUDY+t5FwYqyeINAZyhv1kcADKKuXSzY+NWWQL6Cf7CxaoRS0vkwzkc7J5Km2FSZxG0x7UW35/mlwuvq9jIvpUGBeJRLWzLjA2lYQhMsjsO3iVd+MGPEVlxNYgdjhIfLm5THmSIbaYGluwIEq14wHdT5SccMaWAFrF7dtjLHr4f0je/vVTqQ9H5GXH2xD4vcKVGA== 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 20:31, Yunsheng Lin wrote: > 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. Here are my own premature thoughts just for reference: - If you'd like to provide some performance gain, it would be much better to get a better end-to-end case to show your improvement is important and attractive to some in-tree user (rather than show 1~2ns instruction-level micro-benchmark margin, is it really important to some end use case? At least, the new api is not important to erofs since it may only impact our mount time by only 1~2ns, which is almost nothing, so I have no interest to follow the whole thread) since it involves some api behavior changes rather than some trivial cleanups. - Your new api covers narrow cases compared to the existing api, although all in-tree callers may be converted properly, but it increases mental burden of all users. And maybe complicate future potential users again which really have to "check NULL elements in the middle of page bulk allocating" again. To make it clearer, it's not nak from me. But I don't have any interest to follow your work due to "the real benefit vs behavior changes". Thanks, Gao Xiang