From patchwork Wed Mar 30 20:11:23 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: 12796310 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 EB2E6C433F5 for ; Wed, 30 Mar 2022 20:11:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232036AbiC3UNT (ORCPT ); Wed, 30 Mar 2022 16:13:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231761AbiC3UNP (ORCPT ); Wed, 30 Mar 2022 16:13:15 -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 226C26542A; Wed, 30 Mar 2022 13:11:30 -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 9F5038050E; Wed, 30 Mar 2022 16:11:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorminy.me; s=mail; t=1648671089; bh=U5dIQevY506VUTcHlKOqqtmto/0GP4VFy9OThN9O8gM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eW3U6GA4MKB5nVVfcawq/YhI8dpwuxKYCD4LS8h0yfyP5l38+hWLGEksHNn9v025q Dk/bp+vEmqDQWJYfUtZSMYXow25XpdIJyYeLCyp8wXJOvzj61aQKcr0I9LDkSH/eDE baBQLHh0qU3USpFjqTr8EFdabu9NHTTaujwKTSpYrYPQevOPcq/8LWOKZw8aVspt4A CuS3jhqkmrwiFXoTZzuJv12nsnqLebYyM4zRvJnP4KXDgGcfUfrW1Skipq2cxtbiG1 Wx/9TLtv6pVj9axFId77+fpykxsd56nLD38OERCSdfzPyM+1Cco4ZWh46VzicoDqev T3fE+SobYW6ng== 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 v3 2/2] btrfs: allocate page arrays using bulk page allocator Date: Wed, 30 Mar 2022 16:11:23 -0400 Message-Id: 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 v3: - Added a newline after variable declaration Changes in v2: - Moved from ctree.c to extent_io.c --- fs/btrfs/extent_io.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index ab4c1c4d1b59..b268e47aa2b7 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -3144,19 +3144,25 @@ static void end_bio_extent_readpage(struct bio *bio) */ int btrfs_alloc_page_array(unsigned long nr_pages, struct page **page_array) { - int i; + long allocated = 0; + + for (;;) { + long last = allocated; - for (i = 0; i < nr_pages; i++) { - struct page *page; + allocated = alloc_pages_bulk_array(GFP_NOFS, nr_pages, + page_array); + if (allocated == nr_pages) + return 0; - if (page_array[i]) + 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; } /*