From patchwork Wed Mar 30 16:44:07 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sweet Tea Dorminy X-Patchwork-Id: 12796110 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFD68C4332F for ; Wed, 30 Mar 2022 16:44:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348918AbiC3QqL (ORCPT ); Wed, 30 Mar 2022 12:46:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348916AbiC3QqG (ORCPT ); Wed, 30 Mar 2022 12:46:06 -0400 Received: from box.fidei.email (box.fidei.email [IPv6:2605:2700:0:2:a800:ff:feba:dc44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D94C71D7639; Wed, 30 Mar 2022 09:44:20 -0700 (PDT) Received: from authenticated-user (box.fidei.email [71.19.144.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.fidei.email (Postfix) with ESMTPSA id BB99680505; Wed, 30 Mar 2022 12:44:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1648658660; bh=2vDZxqOwL/Uguo0MetysoT9MQskq4w66hKhbgUWx4og=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rn+gCgUJHYnJ6pCRofwXqyQz3swpxn7noQEe3+0hH1LkMbrG+XvFVzC5D7f07BYvD AfgTpZMFnIZ7ScM3MuMXwQtZGa3MoYU5qOVAA6NEQUAFR2Eyagc4aFYuzpg/kRabp6 N53wUyWHbvjdw1it1W3DLoopUnHCFSl5piMgdwFoLX0BVvTfSaAvy4np5Cm7EfoXZv 6wLUH0oILhDsd62mIQIkGJbnAa6jU+2JVGCY3NdKJD/5NUMUnNcFt334KHLXawc2xS g65TSbNQobORSO8nxioGjhqvj7frTguZIafak1KFOni7/QC+MNmwRUWsrfdWqbxF9e ZzjtrSJyWDIKg== From: Sweet Tea Dorminy To: Chris Mason , Josef Bacik , David Sterba , Nick Terrell , linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Cc: Sweet Tea Dorminy , Nikolay Borisov Subject: [PATCH v2 2/2] btrfs: allocate page arrays using bulk page allocator Date: Wed, 30 Mar 2022 12:44:07 -0400 Message-Id: <4a0be376555602a8ee07b3cb58add0efcce3abd5.1648658236.git.sweettea-kernel@dorminy.me> In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org While calling alloc_page() in a loop is an effective way to populate an array of pages, the kernel provides a method to allocate pages in bulk. alloc_pages_bulk_array() populates the NULL slots in a page array, trying to grab more than one page at a time. Unfortunately, it doesn't guarantee allocating all slots in the array, but it's easy to call it in a loop and return an error if no progress occurs. Similar code can be found in xfs/xfs_buf.c:xfs_buf_alloc_pages(). Signed-off-by: Sweet Tea Dorminy Reviewed-by: Nikolay Borisov --- Changes in v2: - Moved from ctree.c to extent_io.c --- fs/btrfs/extent_io.c | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 5700fcc23271..52abad421ba1 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -3144,17 +3144,24 @@ static void end_bio_extent_readpage(struct bio *bio) */ int btrfs_alloc_page_array(unsigned long nr_pages, struct page **page_array) { - int i; - for (i = 0; i < nr_pages; i++) { - struct page *page; - if (page_array[i]) + long allocated = 0; + for (;;) { + long last = allocated; + + allocated = alloc_pages_bulk_array(GFP_NOFS, nr_pages, + page_array); + if (allocated == nr_pages) + return 0; + + if (allocated != last) continue; - page = alloc_page(GFP_NOFS); - if (!page) - return -ENOMEM; - page_array[i] = page; + /* + * During this iteration, no page could be allocated, even + * though alloc_pages_bulk_array() falls back to alloc_page() + * if it could not bulk-allocate. So we must be out of memory. + */ + return -ENOMEM; } - return 0; } /*