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 6188CE77188 for ; Thu, 2 Jan 2025 20:01:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB7436B0103; Thu, 2 Jan 2025 15:00:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E186E6B0104; Thu, 2 Jan 2025 15:00:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB9906B0105; Thu, 2 Jan 2025 15:00:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A92736B0103 for ; Thu, 2 Jan 2025 15:00:59 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 34D06A0321 for ; Thu, 2 Jan 2025 20:00:59 +0000 (UTC) X-FDA: 82963578642.30.3A6F6AD Received: from mail33.out.titan.email (mail33.out.titan.email [3.121.9.152]) by imf24.hostedemail.com (Postfix) with ESMTP id BA4CC180008 for ; Thu, 2 Jan 2025 20:00:49 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=techsingularity.net header.s=titan1 header.b="W5iTrG/f"; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 3.121.9.152 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735848022; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tcaJKy6bn/A5gvlUdoSM/vlv6uYx1yURwoR7/tabLyc=; b=bVC0D1LZdTU7HtBIYXpHs/zT+cLuNXxn0m6uHSlGBzyh/eZdpcj251OaNVHNc61cycb2bI +5QtKVJLFpRAF47vSYTe+rvEAJDN5VILpZyOleKwQ1thItGA0+StQftLYvs85MqTlbi2fo Z9pMWm5JrVfF+XzI5wTa11rgwFmUCw8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=techsingularity.net header.s=titan1 header.b="W5iTrG/f"; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 3.121.9.152 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735848022; a=rsa-sha256; cv=none; b=o0NxnKHHnRzKN7r2cXBHSxN9nhEd5/aT8ILHa17NHPwWXI5Jn4009rmhqan1/AjRct1Bqg ors8zMwTzwhWCXGHk2EPYUVsCdG2ilh6hlHev3vGJ2SbJPGwYdlfolVdEQWb6KjgRrgDds LjJWbyqmwTp/gfkZFlaaOvIASreDhMM= Received: from smtp-out0101.titan.email (localhost [127.0.0.1]) by smtp-out0101.titan.email (Postfix) with ESMTP id B4B91100070; Thu, 2 Jan 2025 20:00:54 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=tcaJKy6bn/A5gvlUdoSM/vlv6uYx1yURwoR7/tabLyc=; c=relaxed/relaxed; d=techsingularity.net; h=to:message-id:mime-version:date:from:cc:subject:references:in-reply-to:from:to:cc:subject:date:message-id:in-reply-to:references:reply-to; q=dns/txt; s=titan1; t=1735848054; v=1; b=W5iTrG/fuz5K72SKp+vptv0yhUUJGA+nouw48b5j1vGLFlmj4V8O9dn+T3mpr1g6AQFN0KQM 6gXJWwWsCQpULMqlxdjfnpuKl4UOMHa9XgbdB3kFZWj+Yl3kVnf5N+wUxACRrj7YkJFtH+DLIfZ c7oa82htPurTr21sQb0+ZgyM= Received: from mail.blacknight.com (ip-84-203-196-66.broadband.digiweb.ie [84.203.196.66]) by smtp-out0101.titan.email (Postfix) with ESMTPA id ED521100058; Thu, 2 Jan 2025 20:00:53 +0000 (UTC) Date: Thu, 2 Jan 2025 20:00:52 +0000 Feedback-ID: :mgorman@techsingularity.net:techsingularity.net:flockmailId From: Mel Gorman To: Yunsheng Lin Cc: Luiz Capitulino , linux-mm@kvack.org, willy@infradead.org, david@redhat.com, linux-kernel@vger.kernel.org, lcapitulino@gmail.com Subject: Re: [PATCH v2 1/2] mm: alloc_pages_bulk_noprof: drop page_list argument Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-F-Verdict: SPFVALID X-Titan-Src-Out: 1735848054600799869.14999.8406936591630981863@prod-euc1-smtp-out1001. X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Server: rspam05 X-Stat-Signature: g91icrb7qzbcgbs3m45gt83moo37e673 X-Rspamd-Queue-Id: BA4CC180008 X-Rspam-User: X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=T/SKTeKQ c=1 sm=1 tr=0 ts=6776f079 a=RKog28Okct01fxrk7rdurg==:117 a=jU4EnjUUC1PH4wSjvv7Pww==:17 a=Q9fys5e9bTEA:10 a=VdSt8ZQiCzkA:10 a=CEWIc4RMnpUA:10 a=CDkG8U_cDq8A:10 a=gVcTKucYCwh2_j7dxTsA:9 a=PUjeQqilurYA:10 X-HE-Tag: 1735848049-863887 X-HE-Meta: U2FsdGVkX1/c5fvJ3GoIWkpKbKpkxeisU6ApT09fmRxwCYoZfClV3xtfBUHeBdtxWLFFim4ERGA6xVDYk2J9gZZCP4P/D3uizX8S4cnOlSrMayxjLr2vFesvCzkotO7N6Im/bOgdMYnz9PCvwE+cynNJ8Xko1Vnh26EmjHO2II4Yaps5keONVdH8R2w5HndwUxdp2hEwJlHQ+0oqnf8VslcHqYJp1ApmuEQIVE/iWr7ui0y0QBEIcpQy29NMzHrdmjXQNGZoIDkjW5T5d8pfv4UxYywXybwJoZF8iReFjdiBj8YZAX8b7ioTuW1jcjIwRuUB1OSKEUr8V9xZnc9SQZh7UHJ8EcdqFhlxeIAqLDu/LBLD+zUJ21OwzvofbU4p6zuNLP4hN9f7Oj/0B/ZhqXki5IifDbcIh3JzFS5Ywjui0phPDfKE2xC/bqlghFTP6gP4KLb2tP1w7dLWDwDbuz1jqbcFdOrS+P73l/ORIaWmgjUidoMaN6juuEyQl4pvsrMhbftCS36EP6Kwi8md8hP6RRUuS2+PEHwCYWsQ2+1XQdXCO/sbzxFGJBJrF+cjiZB+62zjDmFn/VF0yz9EEMeEJJybfybspuDMV/DwbDtXJ/lGL83X9izv9ARx1TdsFz+48ijkadBkOaFQpH2F8qyA9ENjpBtsOw/BYhj6PmelwuDVOXSs/yrJlpFS+uFXh5wT6ZFqa3bElSl4Z2wbicNsf9lt0baZ+QpnP7OU259+y6S0FoWjpAWVdijB8Z1yJKRFN+OJHpRUC0W7eB7OwU4F0T/QqzOW2L2Jmsm5bYjJ6uDwIzzC+yuB04a5VmpbE7US2YL/qwsorfRtEpMm5lLeDB2w3ValLyJx7wSUB2WyL7TcjPNlkOvEfukmxSfvury5JRcl0drO2xW0xZWFWTEDc5obmY8Nfhr023kqwhigp1MKF92L+gjt/ChQ7SmDS9HtIWbo/O9fud9ZN8Z AEmBT/ri AdCdwgkVCD593XZMjG4JUFnBY5PyuihChKH/q8rCw6wQM7RsH9wMt4OkrjeDv32AwaZetlHHEriJrEnBflbEQxuefsC+ola5uVkWdP9BZATW09bxuikR3jDeM1xNZkg9sZZd3qsqxGjYBdCFySB268h9U8JzLGGBRBAIu8U8Guk9lT1fPWZ0Zk32692B1SpYelKBlIZjaqoc8xRiWz6dVLFFb/Fxj7PDmGL8OdujZ0MT80PK2vwMR68HCO/Rp/O2tJKEe/mR1Z70PJ67fRcYbH7uxNaBpX/e5J8hiWL+YdOHEYIeWMK97ROM1vDy5rCk5DKHAsxqw06Gyx5qW60kL1cnzhlaXzKGlbBYS9wm+2Ex8Y/FSZXabHhXexzd8hcydf9inh3novBmeb9cUgWudtKd7m/YjgYnikdYfY8qBNwxO7n44QSsy91c3s7b7WoqM2dEfcHVPyIAXfrpPTcL8Qcf2PEYCWiSzM6tcBUoPjw4Fn7eey8Hr+zEEKQLSilrkmvj0Wv4hlQcEGYdXoAY0puU+imWtfo/FETBnaT7uoSsmhBzcvqP3cS79rvO/v8bdOt93sLwYmA1jB7byZWJnDsCIVSQGcXLXqKFk6MpMQ3A6MB6/W78vvsHAKEE4IsWIkTtL+parNOIX0VdEj8NdMFTp88YZrS93/EixfFCLqFwgCnPrlJMtf6L/Pw== 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, Dec 25, 2024 at 08:36:04PM +0800, Yunsheng Lin wrote: > On 2024/12/24 6:00, Luiz Capitulino wrote: > > > /* > > - * __alloc_pages_bulk - Allocate a number of order-0 pages to a list or array > > + * __alloc_pages_bulk - Allocate a number of order-0 pages to an array > > * @gfp: GFP flags for the allocation > > * @preferred_nid: The preferred NUMA node ID to allocate from > > * @nodemask: Set of nodes to allocate from, may be NULL > > - * @nr_pages: The number of pages desired on the list or array > > - * @page_list: Optional list to store the allocated pages > > - * @page_array: Optional array to store the pages > > + * @nr_pages: The number of pages desired in the array > > + * @page_array: Array to store the pages > > * > > * This is a batched version of the page allocator that attempts to > > - * allocate nr_pages quickly. Pages are added to page_list if page_list > > - * is not NULL, otherwise it is assumed that the page_array is valid. > > + * allocate nr_pages quickly. Pages are added to the page_array. > > * > > - * For lists, nr_pages is the number of pages that should be allocated. > > - * > > - * For arrays, only NULL elements are populated with pages and nr_pages > > + * Note that only NULL elements are populated with pages and nr_pages > > It is not really related to this patch, but while we are at this, the above > seems like an odd behavior. By roughly looking at all the callers of that > API, it seems like only the below callers rely on that? > fs/erofs/zutil.c: z_erofs_gbuf_growsize() > fs/xfs/xfs_buf.c: xfs_buf_alloc_pages() > > It seems it is quite straight forward to change the above callers to not > rely on the above behavior, and we might be able to avoid more checking > by removing the above behavior? > It was implemented that way for an early user, net/sunrpc/svc_xprt.c. The behaviour removes a burden from the caller to track the number of populated elements and then pass the exact number of pages that must be allocated. If the API does not handle that detail, each caller needs similar state tracking implementations. As the overhead is going to be the same whether the API implements it once or each caller implements there own, it is simplier if there is just one implementation. -- Mel Gorman SUSE Labs