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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C86F3C433EF for ; Mon, 28 Mar 2022 22:11:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229517AbiC1WNg (ORCPT ); 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) 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.