Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1753495pxb; Sat, 2 Apr 2022 02:07:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNvuPFckI1wKSZOzw9RKqBZ5smUw+nyLGfgQ/TRp/k91MSmz6GieCyVcktMyHaaQHC4aNY X-Received: by 2002:aa7:c948:0:b0:413:2bed:e82e with SMTP id h8-20020aa7c948000000b004132bede82emr24367023edt.394.1648890454883; Sat, 02 Apr 2022 02:07:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648890454; cv=none; d=google.com; s=arc-20160816; b=yO9G9C1zWqEjmKL9tDreVOGNb5AHj2gfc4URqwYlihd+/1gUlktM72BFua2ksZWN3L nqjwEN0mIX8AlzEeCwtctEoBcxtSUNG1FWz1ugwwxLYMdAwH23m7efUE+TGZ2wq0fWrj CrMudVL7vEg68Bf8NQtKU2bcTZ5JhL07VmxK3cMBY1Q0H7ZVheBBPp69kRrQQ1NLIPNM 1faavrjEZ2fjhnHFwP0PGOIOE5PTh0mqPgUg6qgXxMdvt7W3IYysyHu1yx8I2xiJkfez Za06EjX0qvnLlKN83GZ1ZoRTpccXTL2kQ5b40mjLZu57uWHuYKoA2kfhkzOxznmAZYwM xORQ== 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=pbRJr7IPn8qeEu81RK3Y+vqOSQRcbz2LMBzi+HgbIr8=; b=qrPKrHoJ5DxNNkdrwHs0sTKj3REahwF3pT6SQD1WljT/D6M4CDYLcFf0qIMNChLKVo 4IVugjKJxigklzJPjZv3O6agkGzyWeo0TGHTGj33dKjIjBknkjgzHuXUjeerACJT/xMu XHfBl/GacnahTFGQiSnBc0cBvzabHzyWmwHrczAwACJzinU1+kfgWE7d1gOaAjnx9t7a i6bJ7ZWlN0YTBSoIGmquL6ENtc6qI+7frHapbEuikUPXWucO1VGNsa0AIU5CNW0wexGY NDXbExFa0JDb/k23oTeTQYAie+lgHO+iQmmeKfDEus3oaFwlUDikqVxH51YmNve/HOr1 bUKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=TPMSwncJ; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dz8-20020a0564021d4800b00418fb7e2a2csi3211458edb.78.2022.04.02.02.07.10; Sat, 02 Apr 2022 02:07:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=TPMSwncJ; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346350AbiDANbw (ORCPT + 99 others); Fri, 1 Apr 2022 09:31:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232890AbiDANbu (ORCPT ); Fri, 1 Apr 2022 09:31:50 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34C73276FBE; Fri, 1 Apr 2022 06:30:00 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7C173210EC; Fri, 1 Apr 2022 13:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1648819799; 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=pbRJr7IPn8qeEu81RK3Y+vqOSQRcbz2LMBzi+HgbIr8=; b=TPMSwncJZtNw918WLa+hnrGEKvZieut+mublksy1AsW1fKAp3kqDx6QhzYCm0gjr3DjKGN YIDrpzZHz16i7J5g8VXY6aFuHmhgqgL8UI1CrMfMNrvT18N2Fzp1rLZ811jHeJ9xjbbRKS sBU+HNsM4/tzebwGmFzotiQvkWHA6QQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1648819799; 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=pbRJr7IPn8qeEu81RK3Y+vqOSQRcbz2LMBzi+HgbIr8=; b=PnsAKlVlpalyVK/QMAf1uoZqLPQbGAE63ACdZs5Q8Waq0BcpDskylPQby35lqHnyrLZvYw itMrDdGmwU/ZZODg== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 6F8B4A3B93; Fri, 1 Apr 2022 13:29:59 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 64C3DDA7F3; Fri, 1 Apr 2022 15:26:00 +0200 (CEST) Date: Fri, 1 Apr 2022 15:26:00 +0200 From: David Sterba To: Sweet Tea Dorminy Cc: dsterba@suse.cz, Chris Mason , Josef Bacik , David Sterba , Nick Terrell , linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com, Nikolay Borisov Subject: Re: [PATCH v3 2/2] btrfs: allocate page arrays using bulk page allocator Message-ID: <20220401132600.GI15609@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, Nikolay Borisov References: <20220331173525.GF15609@twin.jikos.cz> 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=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Thu, Mar 31, 2022 at 02:19:07PM -0400, Sweet Tea Dorminy wrote: > > Also in the xfs code there's memalloc_retry_wait() which is supposed to be > > called when repeated memory allocation is retried. What was the reason > > you removed it? > > Trying to keep the behavior as close as possible to the existing behavior. I see, makes sense. > The current behavior of each alloc_page loop is to fail if alloc_page() > fails; in the worst case, alloc_pages_bulk_array() calls alloc_page() > after trying to get a batch, so I figured the worst case is still > basically a loop calling alloc_page() and failing if it ever fails. > > Reading up on it, though, arguably the memalloc_retry_wait() should > already be in all the callsites, so maybe I should insert a patch in the > middle that just adds the memalloc_retry_wait() into > btrfs_alloc_page_array()? Since it's an orthogonal fixup to either the > refactoring or the conversion to alloc_pages_bulk_array()? Yeah a separate patch with the reasonig about the potential effects is better. The v3 is now in misc-next with the suggested loop refactoring, so please send the memalloc_retry_wait() update on top of that. Thanks.