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 51D9CC28B28 for ; Mon, 10 Mar 2025 00:11:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86F8A280002; Sun, 9 Mar 2025 20:11:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F7E8280001; Sun, 9 Mar 2025 20:11:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67363280002; Sun, 9 Mar 2025 20:11:14 -0400 (EDT) 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 4790E280001 for ; Sun, 9 Mar 2025 20:11:14 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C0085A7DCD for ; Mon, 10 Mar 2025 00:11:14 +0000 (UTC) X-FDA: 83203711668.06.74FA94B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf21.hostedemail.com (Postfix) with ESMTP id 8A1E21C0005 for ; Mon, 10 Mar 2025 00:11:12 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=KDwNqFoQ; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=CKCBvC+q; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=KDwNqFoQ; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=CKCBvC+q; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf21.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741565472; a=rsa-sha256; cv=none; b=5GHDfrzkN/jL8WJvMyb4QsvxF9bUIeQE+7KRJrQ7yIAc8cDssjalChDqSQnrDw9uf8+6Gh Jo4iqlI3OZSIM95Z5rxmdGXpVBacpek0/53fRo1bvK2MMIqSZJfJanITHC6J9dvxvHat3F vvza0fIywx19g3Fz5AXvciRFaZtpO+k= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=KDwNqFoQ; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=CKCBvC+q; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=KDwNqFoQ; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=CKCBvC+q; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf21.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741565472; 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=VKyzFF9sqmXYhDyE0Ctknq3rDxkaHE2kfW5qcx4F3Vw=; b=zdD/wVchafPYbAooj+t6aaiyuwgvOUcSyCWU+bTrqECis9sJSzjgZjFuw6/CkS6LBb8nE9 qOGy0Tj64zxnUono4I2sYIS1fW2pliuJxHlbvI7poi5QEqQLHB52pZoefhutSiukMJhsnr 8vbOWiCHDnUH39rWDnvkGUuNZgxx2s4= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 37A3D21165; Mon, 10 Mar 2025 00:11:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741565470; h=from:from:reply-to: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=VKyzFF9sqmXYhDyE0Ctknq3rDxkaHE2kfW5qcx4F3Vw=; b=KDwNqFoQ1OfaFxm4+cFRAPQG/9lynj1ynPLvXyUtW/eDH0KUuIYqPg5O72cpxP/Zk1C/Y+ mehlBAkI9r02PjZFfCVLIG6S//j5OTq2c8ulSv29hm21UuGi+iN+usKAhsqGTGV0XBYiJa mmhD6HUTTzVjz6QdBRenk6UuDxAESdM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741565470; h=from:from:reply-to: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=VKyzFF9sqmXYhDyE0Ctknq3rDxkaHE2kfW5qcx4F3Vw=; b=CKCBvC+qBGhb131WpP1iP4N9DXwY1T6wcW+5i8EpcqALKXBl5exCvK3fTYcuJC9NtT9axO 1sE6tGKLUorcLgAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741565470; h=from:from:reply-to: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=VKyzFF9sqmXYhDyE0Ctknq3rDxkaHE2kfW5qcx4F3Vw=; b=KDwNqFoQ1OfaFxm4+cFRAPQG/9lynj1ynPLvXyUtW/eDH0KUuIYqPg5O72cpxP/Zk1C/Y+ mehlBAkI9r02PjZFfCVLIG6S//j5OTq2c8ulSv29hm21UuGi+iN+usKAhsqGTGV0XBYiJa mmhD6HUTTzVjz6QdBRenk6UuDxAESdM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741565470; h=from:from:reply-to: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=VKyzFF9sqmXYhDyE0Ctknq3rDxkaHE2kfW5qcx4F3Vw=; b=CKCBvC+qBGhb131WpP1iP4N9DXwY1T6wcW+5i8EpcqALKXBl5exCvK3fTYcuJC9NtT9axO 1sE6tGKLUorcLgAw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 22EDB139E7; Mon, 10 Mar 2025 00:10:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id vGLtMQ8uzmfhQQAAD6G6ig (envelope-from ); Mon, 10 Mar 2025 00:10:55 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Yunsheng Lin" Cc: "Yunsheng Lin" , "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 Subject: Re: [PATCH v2] mm: alloc_pages_bulk: remove assumption of populating only NULL elements In-reply-to: <7abb0e8c-f565-48f0-a393-8dabbabc3fe2@gmail.com> References: <>, <7abb0e8c-f565-48f0-a393-8dabbabc3fe2@gmail.com> Date: Mon, 10 Mar 2025 11:10:48 +1100 Message-id: <174156544867.33508.5386967459254083056@noble.neil.brown.name> X-Rspamd-Action: no action X-Rspamd-Queue-Id: 8A1E21C0005 X-Rspamd-Server: rspam11 X-Stat-Signature: p8s8bx61ttr7wp181in3tmfuisfkoim4 X-Rspam-User: X-HE-Tag: 1741565472-806730 X-HE-Meta: U2FsdGVkX1/iGt67b5l9RoBznxff62SdYMgFqcUKDHAiXKaLcdUwoZpUpfuHJZ/RUX1QdO32k0uogq713muWH/FjzDwvODrf5O2kwl7eA25hN+lyWHN46D5qYH9xiquqQYHfF/ELPtCeuXctsREi227CGUkLjIisSVdFGuN9xG1L3F3BNJKu54JRJ7ijlPEQ24OOEtjg+TRgKPPvXOXJwXhb6N+1gkQTr2IMn9+Bz6WfgkXJyWoxINOJAVfBt+fRg4EZl/usI74gyGT6rmOlMw6DRLwDrWF9dp5OVcewTpDsMdRJEYufaDFIup+yXuTQBVS5Pc3c5fFhhBw01gCRiKiix5rsHt2kr+F2YK4nxqetj5QXiF+Q44bwyzG1ui+4YT0AkdqWqCamXyezF691NogAB42mrzBtjTCvMiAB61j87VLdHwLBgP5ZR7hK0cjDTC0h5LUDJlLleqlW8CMXmsZfWPIhdNInBDnIm1RXblm7NosdEdrFn+B/DEl1qncAY4Pgy4ugw2nArQtaDaxBhM/WcWX7eY/7VEw1qFqLCwKpYkz//HDZmSkIl3vE2DyKMJ95Kbzr/AAnWXxHY+ILwI13vqfg/jXlgCBye6CpW2AekMjOLkU3Mccq2SwW9Igr6BDZAFq43L0VGD9s9+ZMXO880Z2/9aC69Wsnpisu8C2hT0N77K8ALmrDcqVX0yDcObkzKXXqgtd2sP09aiyJas6nkPf4ItPFS8KRAcOQlrnDVwHrl4cHxB65dJNdxNK8Ju4bXa29d9yCwouZus2nil5EjW/CozFR4mustdj1rmr0y2YoUI9GCNODOOAEGndeJ3aCzBIdSm4axbmnNKH6NIBgJKKY/dWm/ecNSZvbdZyjVM/dxjmthBBhCKtglut7oLY6jEHT+xMHSTK/sTi6yMwskLBCA/SR57dA8lnGBHTI4S6jZiMorAUOvzGTJEIVPrXRPO3E1B/gCzHNKlY ySF2JAfM LGTZsTLb8p6rYEzt/j+ZQLb35Ov680Y0BUiq2DecBNbz6OmCQFPOmOfx1GKaBOVIHeHIeTJavXiAHSONTar4vcQ6/+IF70trzM/jZ9qNXQ7mm95FAwsWmIQ8gKXR1XSISyX8rSfjR2QNpTOnK9VioJkp78FvFRwnxvRLyLI4EfPLowzHLUBltF4a2msnwQi8piH+XFpjbUaHGuwcs3xClqQWuLNU7idj0bn7poV/b/nMXQmvtDgDgQ68Jcrlh/AJPkjc0ct/Urd7a95umUiiMP6yNcnoCcTiNZ/OBCrJLNXdYv6LRfkbjpqlLiuIV86F2qCgopZ6Gf1XixO9CxSslk58qmMD09Mvkuuk1AxMC1U168/7uTLjmmPJI4JPJ40itv15m 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 Mon, 10 Mar 2025, Yunsheng Lin wrote: > On 3/8/2025 5:02 AM, NeilBrown wrote: >=20 > ... >=20 > >> > >>> 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? > >=20 > > 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: > >=20 > > - 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). >=20 > Yes, the above makes sense. And I guess returning '-ENOMEM' & '0' & > '-EAGAIN' seems like a more explicit value. >=20 > >=20 > >> >=20 > ... >=20 > >> > >=20 > > 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. >=20 > 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'. >=20 > I guess I can try with the easier one using array defragmenting first, > and try below if there is more complicated use case. Your post observes a performance improvement - slight though it is. I might be worth measuring the performance change for a case that requires defragmenting to see how that compares. Thanks, NeilBrown >=20 > 1.=20 > https://lore.kernel.org/all/f1c75db91d08cafd211eca6a3b199b629d4ffe16.173499= 1165.git.luizcap@redhat.com/ >=20 > >=20 > > 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 > >=20 > > The "dispose of them" is one of > > - add to a linked list > > - add to end of array > > - add to next hole in array > >=20 > > 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. > >=20 > > The three functions: alloc_bulk_array alloc_bulk_list > > alloc_bulk_refill_array would each look like: > >=20 > > validity checks: do we need to allocate anything? > >=20 > > if want more than one page && > > am allowed to do mulipage (e.g. not __GFP_ACCOUNT) && > > zone =3D choose_zone() { > > alloc_multi_from_zone(zone, dispose_function) > > } > > if nothing allocated > > alloc_single_page(dispose_function) > >=20 > > Each would have a different dispose_function and the initial checks > > would be quite different, as would the return value. > >=20 > > Thanks for working on this. > >=20 > > NeilBrown > >=20 >=20 >=20