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 3A85CC28B2F for ; Sun, 9 Mar 2025 13:23:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9594280002; Sun, 9 Mar 2025 09:23:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4733280001; Sun, 9 Mar 2025 09:23:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE582280002; Sun, 9 Mar 2025 09:23:54 -0400 (EDT) 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 90BA1280001 for ; Sun, 9 Mar 2025 09:23:54 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 68AFABB3D8 for ; Sun, 9 Mar 2025 13:23:55 +0000 (UTC) X-FDA: 83202080430.26.801C4D1 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf17.hostedemail.com (Postfix) with ESMTP id 69CFA4000C for ; Sun, 9 Mar 2025 13:23:53 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kuNr26qs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of yunshenglin0825@gmail.com designates 209.85.214.196 as permitted sender) smtp.mailfrom=yunshenglin0825@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741526633; 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=78f5GfsZLdHs7HcZYqhufn9bqBeaLB9GfsmUNDdGsAU=; b=psTLvuO+ALo0TW6ZqI9g+jPAXYhQyU9z08egOuawzaww87LHBU+uDhwZNcB/1NJzWYN+c1 dvn64pLUfREmYcVft5w6OBev1FNufivTABJammQLwgxFohaqgyBG12hvTrsON0rIGi/cDw uE/KvH7YZ630Tst5f74c0wuWQmFkftE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741526633; a=rsa-sha256; cv=none; b=R4SDUphW+cmlZhxk8xWXZzbl3S8zHERH8GWvQDC0XixCqCIPK7bBpwSJPlK8tdjNZY9rzJ m0ZY5Y07zRfM5AmTHBUq56sIF10XBNsH2JgdGUATH5C3TK+yVfSOQ8OBOdPwUOT/2Xmzk0 42mQnIpQaoRcD8dP79leRx5pbsg07CY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kuNr26qs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of yunshenglin0825@gmail.com designates 209.85.214.196 as permitted sender) smtp.mailfrom=yunshenglin0825@gmail.com Received: by mail-pl1-f196.google.com with SMTP id d9443c01a7336-2240b4de12bso46373675ad.2 for ; Sun, 09 Mar 2025 06:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741526632; x=1742131432; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=78f5GfsZLdHs7HcZYqhufn9bqBeaLB9GfsmUNDdGsAU=; b=kuNr26qsIehOn4yWcyTNP5biQV0kn/PVwHlpFr6X/O+kVmk10Q5qTnwvLN6p+G2fzl hoVHb7XqMpKfIImMLvcZQBbmO0DXPLHFpCLlHcZ62wGOMuI9IKNDEbuAGvaLA3MiRVKF fb4yMkxpadoJC0fa+PcnufS1EbcsWK+L+hF+9Krsu2RXE6QqBfTSC5558h/ZQ6Ytkpfi IhA+0uweS3+OImNlmBY6H3QtMcQ0LcMaBNbhzKcbtJFVhgbdo8fprjLfqP6eQXjP86jo AHCKmx1KavOSweeKAwJ0Y4h+4diovmBI+KWsO3z5rWeoqdTlyB3iuZaHIwEpQS76h2JF Te7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741526632; x=1742131432; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=78f5GfsZLdHs7HcZYqhufn9bqBeaLB9GfsmUNDdGsAU=; b=DvxSs4uwz4wdLRqXMr9IXhaAi03eUNSL7aWIvC+x57ohgAGYOpckPaModt8VMY0fRQ DsmNFunFEHEYin2UvHfg/Fto+4Btuto3VT1XKJRJDDfaPPUnqzqluaxk3Qix1l9rMOYb gjDUSsrybhl6zxehFHAxa8CmuphASgNzvzTMSYcnwHVRfkToxdVev1oJM93B13q55167 JHDvit1EdtvTITpgesOpLiHN9KwfKM6j6F1eL6awHs2ekWsLGqHizOTCfo4YBmaeKwpX cS2wH/81lRoxObCkgOnUCJ4UmYrsAhFvSHjDgAVltynAlOBuwRQXxLyzV0nRM7VTv2ca YRIg== X-Forwarded-Encrypted: i=1; AJvYcCWUvXNK00vh/EIm4bapyIZBczTwfZB4RLiDcgA1nHlG2QtE+e/Fxwd54u2E/fNPDSBoibP7Dzp+3g==@kvack.org X-Gm-Message-State: AOJu0YyCMSMhTWFhJIaSSwhzGtL2k3P5nEdVaM0k86aEG1y12yDGNMRp MRxDIN1R0cGydmzj4Cntf4aOeqFxPhtpP+uGkkdDs2/NLLQp5NCJ X-Gm-Gg: ASbGnctA1Ud18TofGixNkNumXUoiG6yjsLBwjioRvdn0tmzA2nWIgcqQsudssXedrPG LEuoERcHVq5jr/R6ub6cYmK32+vONIAAoIZGEGW/S5PccjKdfRHmpoGeY+z4GjfsyFsOgaH0sYG J0RVpQTZluPFouR7TaZPA88nAZAVwCP8W4V+Zwr/qdAcIS00oB4CFiupV7wiYFsvMdVaBBJVkWl j+NNQvXf60/MFOaJGppOrNp2k4V63F6+BfX90qi+mBD2G1Wq6SAV7JApMW/xxDZiDjoup9aowNr owMRQmLedgX09Nwysbzvl/vK1y2JWp9/dyH7iJisdg7sjBRhpmdIaJwz4fvQD04Wch2U/JsUUXC q8z+1HOx1ATB1OFf760syS1JAw4QWIY6H1k988bNV X-Google-Smtp-Source: AGHT+IFtC936bSg/3HregqNsD+RiIvE+I7Cf0Sja++qaGUNlZeLkZuXJlqOzuqqV2Wpl3dx1MeKXQQ== X-Received: by 2002:a17:902:eb81:b0:220:c86d:d7eb with SMTP id d9443c01a7336-22428ab863cmr167985465ad.36.1741526632153; Sun, 09 Mar 2025 06:23:52 -0700 (PDT) Received: from ?IPV6:2409:8a55:301b:e120:c508:514a:4065:877? ([2409:8a55:301b:e120:c508:514a:4065:877]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-736d4f20913sm597161b3a.13.2025.03.09.06.23.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Mar 2025 06:23:51 -0700 (PDT) Message-ID: <7abb0e8c-f565-48f0-a393-8dabbabc3fe2@gmail.com> Date: Sun, 9 Mar 2025 21:23:35 +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: NeilBrown , Yunsheng Lin Cc: Qu Wenruo , 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 , Olga Kornievskaia , Dai Ngo , Tom Talpey , Luiz Capitulino , Mel Gorman , Dave Chinner , 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: <> <180818a1-b906-4a0b-89d3-34cb71cc26c9@huawei.com> <174138137096.33508.11446632870562394754@noble.neil.brown.name> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <174138137096.33508.11446632870562394754@noble.neil.brown.name> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: rejtf8crueghidcrx4ujpic6fyme3pas X-Rspam-User: X-Rspamd-Queue-Id: 69CFA4000C X-Rspamd-Server: rspam04 X-HE-Tag: 1741526633-176955 X-HE-Meta: U2FsdGVkX1/vll5OF8gbpfnyRD6r8G3dp78ohMGcW7RgzVipW1M73YXwNDW0qI/ajYUasy9ZLd2TNdkw32UgoHRZNAXHJX1Mn3HZl6RD5knn6MMYhbyoWbWmze0r+F5iLgqCoKdbrwY5rUwymwzzriMV1vUNWo5yejqc7JWHlEcqNzGfzeT5SiF33c3r4QbkA+xqZlpjE4PqvlftWl8Z3n5lYak5MLkYGw3x9VVgOzCODcf1/q65VsqPMhx4KUBOlq+OOEBrQetQHwHN1mVP07fffjsO8Ea+fZv+VxyGHaASrAzlzmVa32Rq+OhnqAi2cPCiENJP2PIonWDaO+e2P/aVq1ueCo5yh5k04G8y2PxPVzD38YGMKsVciv7Trsrhq5RkoAIVp7wKCltl7yQf4cb5z390Em+A4LOO2zFq85b55ieAeAUIzJe/qmonro8fX9twG2akFlO/JvuVTTue3FdmTtSeiKBC2BTPek672HN0qlokJONB1qjoXvzVDa/UGBT1cKX2EIiD4CggPcMP7+PYU2cUB8gm1YrxKMJBUxIpxD9Z+9Gisv4eIquMcVu+6dyvqAWybw6tcbkdpLlsstewizUKz+VVpS/lp3xZ7eyCEeHg9wUEMghis+UMRdFzD9CUGcAvscoaU8KFB2qE28U6uNjLAiHiHvKAVczxaKbxAk159nJ7WenAAoqtfUWv0gglO3LDDkbZRNa28FAIeR3qOsoG+gXMSrlujA4mB8hYvI4xiWkkjELWaDK/0ztlTSxzntobB3LWCsKG2/fs1gXRwT4wQx5Ce0yxD5L4T44y4gfkXDInjX8qBdKLOgmzN0bCZCUet9ULGYn9WuGU8HZHTW1eg6YY5zVfquhJoDJFv0LtL2otaUpRh1CxNyhraHM3ZTgJdFgyZ11zWxMZlWMgqvNKOWo6Qu3TBm+FysC1afHcexLOMRxwxiRW/xDBPkE66xYF0fcJ9+QsFIN KEQ+67r0 8Rh3LY/rC20DtBExwbtiTsrvi1xHpGoyLX6AfxCUqua+SKutIkLKEjWtc/5Lju1T8mnUiOdNjNeHGYyh24mCscfWunReBWh4lnIdf9FoOxRHL2PaOp0krYXo4r+2PH58ocKF9d2Ca5GPn+K3rj5aej19aT9dyaRVlWKTIrELTLF7mDgcwgtg+AndFkHYofbbef3NqiR/XexZBdevLMvg6/3ZYkg1ZrHMNzHNZsPSbiEFoLc8t/OKJwm7iOmn24n0rmI7kJiWEShLIT9KBYqcsa2xCAApgg+mQt/PDTYoLd2RLmVrc+WxGo6oyp1gtL2FqQwN/S+OBr00udy7svkhwsw2fuNTswwNeG4rzkceUR6VLDaAxYz5FUq2T7LAiE3c1KEZrsxn4ndVRWZBdny5021k63R2EDsPJDGzctNZHser07rgRiYMTPe12fy/8NFnhobcl4WjJABiT8BTUEeysqDSfoZn7oaIObh9UsjxAzvvGGXKp8MuPp+fPn+bhTGDqtzNkFCMkycrl9S1/Y1Ra7vfXFDyfhNs+D8CE 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 3/8/2025 5:02 AM, NeilBrown wrote: ... >> >>> allocated pages in the array - just like the current >>> alloc_pages_bulk(). >> >> I guess 'the total number of allocated pages in the array ' include >> the pages which are already in the array before calling the above >> API? > > Yes - just what the current function does. > Though I don't know that we really need that detail. > I think there are three interesting return values: > > - hard failure - don't bother trying again soon: maybe -ENOMEM > - success - all pages are allocated: maybe 0 (or 1?) > - partial success - at least one page allocated, ok to try again > immediately - maybe -EAGAIN (or 0). Yes, the above makes sense. And I guess returning '-ENOMEM' & '0' & '-EAGAIN' seems like a more explicit value. > >> ... >> > > If I were do work on this (and I'm not, so you don't have to follow my > ideas) I would separate the bulk_alloc into several inline functions and > combine them into the different interfaces that you want. This will > result in duplicated object code without duplicated source code. The > object code should be optimal. Thanks for the detailed suggestion, it seems feasible. If the 'add to a linked list' dispose was not removed in the [1], I guess it is worth trying. But I am not sure if it is still worth it at the cost of the above mentioned 'duplicated object code' considering the array defragmenting seem to be able to unify the dispose of 'add to end of array' and 'add to next hole in array'. I guess I can try with the easier one using array defragmenting first, and try below if there is more complicated use case. 1. https://lore.kernel.org/all/f1c75db91d08cafd211eca6a3b199b629d4ffe16.1734991165.git.luizcap@redhat.com/ > > The parts of the function are: > - validity checks - fallback to single page allocation > - select zone - fallback to single page allocation > - allocate multiple pages in the zone and dispose of them > - allocate a single page > > The "dispose of them" is one of > - add to a linked list > - add to end of array > - add to next hole in array > > These three could be inline functions that the "allocate multiple pages" > and "allocate single page" functions call. We can pass these as > function arguments and the compile will inline them. > I imagine these little function would take one page and return > a bool indicating if any more are wanted. > > The three functions: alloc_bulk_array alloc_bulk_list > alloc_bulk_refill_array would each look like: > > validity checks: do we need to allocate anything? > > if want more than one page && > am allowed to do mulipage (e.g. not __GFP_ACCOUNT) && > zone = choose_zone() { > alloc_multi_from_zone(zone, dispose_function) > } > if nothing allocated > alloc_single_page(dispose_function) > > Each would have a different dispose_function and the initial checks > would be quite different, as would the return value. > > Thanks for working on this. > > NeilBrown >