Received: by 2002:a05:6512:2355:0:0:0:0 with SMTP id p21csp5529765lfu; Mon, 28 Mar 2022 16:04:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHSY5O7+EZGMJ3PnzJKnyDdRsasfkB/uL+WxVF4vb7LBZrT5PJ1yD2K4unnZzfVzqwxy6l X-Received: by 2002:a05:6870:b39c:b0:d1:4a9f:35f9 with SMTP id w28-20020a056870b39c00b000d14a9f35f9mr701833oap.119.1648508651294; Mon, 28 Mar 2022 16:04:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648508651; cv=none; d=google.com; s=arc-20160816; b=K6HIzYDgzFbSq4CPrBnzlaPRe4T46XXsFTw6EuZLdA2tbCfNsoQ0Q83vBSkWmLw4pR 1DJJ0UIKbtT89nKjI+KdWm3ewlvqD7yXlVF0AU8jboIgMSdu4epRWxrhcek6JO5iTxQ7 okx9OXmGtPPI74+ucL9gkB/fVmr/V5QNvpkK9XbRhYtWHyolOjO9NTvviFKmJqhdEOD2 GGAN4dFQu6+JckBm0Sqz1pGH+rvn7cZ44kceoONz/BTGZ77NNQbOafCZJsWMKP6ayhFE kLLPIRwjrjZvhWV/OzzRohMhkAo/+3I8PFWEb/qtwSpn7RbGqJ9904XMzuHkoBOZM6Q/ n/qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=rYFGS9AYzxVsx9knDBb4jcUDE3645z2CTIc2cXxxBpM=; b=ZhEVEinETZ0qHus8TxuQBAWLBDHSP3ZXyIJL5XuE1XVPFd40HwVJ+CbNNOvTLnycL3 dDa8zJxkv/c5r4RpTUdbt/LgaWA4u5uLqmcQ4L94p6f5iqva4Ii5nZmdA+jzi8EOfUhC Dbfy8vbvyMEvKxtqqa3wm79Y80++8qilLtoP5io5rqOfcyE0+U1XszFN+UZaad1t5BGL p8LhMqErTTais004WI/8v57cJs9Qtyqj2MQXuWHM+nDRe33fzJPXPPdsHsfZ66YgqQ6O NVArtvNJWE6aZw5LBpqjZ2f1FIrR3LhcyGPgI5JCREpWUisxI5qZBsFYUSnwfXaawRY4 /6OQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=0soT1ko2; dkim=neutral (no key) header.i=@suse.cz header.b=tZBEhRKf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c5-20020a9d7845000000b005cb2fc13891si11620257otm.269.2022.03.28.16.04.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 16:04:11 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=0soT1ko2; dkim=neutral (no key) header.i=@suse.cz header.b=tZBEhRKf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 975FA2986D4; Mon, 28 Mar 2022 15:12:00 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229511AbiC1WNg (ORCPT + 99 others); Mon, 28 Mar 2022 18:13:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbiC1WN0 (ORCPT ); Mon, 28 Mar 2022 18:13:26 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BDAB13E42E; Mon, 28 Mar 2022 15:02:22 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id DED2E1FDA9; Mon, 28 Mar 2022 22:02:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1648504940; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rYFGS9AYzxVsx9knDBb4jcUDE3645z2CTIc2cXxxBpM=; b=0soT1ko22OO/7z4QLN0QnF8+IKnrsF+Q8yRaz++XBb+qqIXDWjmrjUzZlmY1nR4o9B8VCT g8LoEDjuYZqXWXAVrUS7pWYDCBpMpgQ5dgFiKE2JVHTcwZDZIYHmw60DTHhPPZhNDegNQz aRthzkd57oYYo/684UBnFlh4HZOJumY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1648504940; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rYFGS9AYzxVsx9knDBb4jcUDE3645z2CTIc2cXxxBpM=; b=tZBEhRKftWDILuZsN9gHgfpd2FAfOGHdKlv3I5ZVGNuvwAnQRItPQXCKb5G8KdXdtdTgQw ADB02uAof+v3rACA== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id D0E53A3B87; Mon, 28 Mar 2022 22:02:20 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 937FBDA7F3; Mon, 28 Mar 2022 23:58:23 +0200 (CEST) Date: Mon, 28 Mar 2022 23:58:23 +0200 From: David Sterba To: Sweet Tea Dorminy Cc: Chris Mason , Josef Bacik , David Sterba , Nick Terrell , linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 0/2] btrfs: Allocate page arrays more efficiently. Message-ID: <20220328215823.GV2237@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Sweet Tea Dorminy , Chris Mason , Josef Bacik , David Sterba , Nick Terrell , linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 28, 2022 at 04:14:26PM -0400, Sweet Tea Dorminy wrote: > In several places, btrfs allocates an array of pages, one at a time. In > addition to duplicating code, the mm subsystem provides a helper to > allocate multiple pages at once into an array which is suited for our > usecase. In the fast path, the batching can result in better allocation > decisions and less locking. This changeset first adjusts the users to > call a common array-of-pages allocation function, then adjusts that > common function to use the batch page allocator. Makes sense, the allocator internal knowledge can improve things. Though after some time the memory often is fragmented and the bulk allocator could fall back to single page allocation, it won't be worse than what we already have. I have some coding style comments, will reply under the patches, otherwise the series looks good.