Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp773100rwb; Mon, 26 Sep 2022 05:48:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6BiymCbL6l0N3OnljSZ29GX+UVrhcNuc/aX11EauCWeRzYxdO5CWBgXNPFLhZL0x0kpkVi X-Received: by 2002:a05:6a00:2491:b0:544:2599:6f08 with SMTP id c17-20020a056a00249100b0054425996f08mr23243851pfv.47.1664196500162; Mon, 26 Sep 2022 05:48:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664196500; cv=none; d=google.com; s=arc-20160816; b=mU7ia7Ne6Uyr8cSS9i6olFACJQ4s5+p6kelCdXI3+IwCAnor4WECdyIzJ0Ee+hA4w0 kPA46gF4j1HhIxeuMno4PXwd0QKitBASu2fKyWyEZcPGbaAnnY067RIRU/eo4gVqslwP 9YAGAEhvr/0gFWSWtJsKq7jnw0FPrMFpop6kNPOeRUM1mqflWEgTkH13gPp8lRFfwVCs DQH0hK1VZPG8/we2LDN0u7TiZ0KKtYqtKjB3oNnpGbB/dtW4DEop/RgR2ivj3xp7p2MO i/49uttVNzCwhREPrIfoEQ1ISKDyQh+CDpcDIqOLH2nk+JDgH2urnuXzHIEw8vDyoKT/ LrEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=TThZQg5MuFuyhlGu4Khlz+KnIQO4BhiooKUiX2Z4QzQ=; b=JkcvLQ+Gb3A7Bjsbzt7eellS7ZipcrvyJ0u415ReggJflowo+edxqh4Rj3KFZV8Y5G i6M0U5MU2xwaBBSLzXWN79KCX0Bj2YJkJo/6/f+rQ7GqAxdnJsyJa9twPIRACrxsu7k5 TatOYDfyZvGwLheJ7rxZGkK3kXhDCQLaMGcSR3tfgKC2y6PI7YeRMBHPmxmFyDKx4+ak h77he8fI39SgRBTyTjMDr6+6uCkQVMzAFgrajjMMVEZzyVB8mR+KAdyADRWmdaYZGaqw 8Nz0c/yegz4ckzzjYQShp2TreeUmHIyul63BMbRh5A6tZ+y7QB4p5zUL466g8alFSTZC imUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dArzhztT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t6-20020a170902b20600b001781cf050b6si11213744plr.14.2022.09.26.05.48.08; Mon, 26 Sep 2022 05:48:20 -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=@linuxfoundation.org header.s=korg header.b=dArzhztT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239401AbiIZMJv (ORCPT + 99 others); Mon, 26 Sep 2022 08:09:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239204AbiIZMIM (ORCPT ); Mon, 26 Sep 2022 08:08:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEDAD7FE50; Mon, 26 Sep 2022 03:56:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 27DBEB80883; Mon, 26 Sep 2022 10:41:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84946C433C1; Mon, 26 Sep 2022 10:41:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664188865; bh=N5RpwwG/mgc1T0SA0xNuDXrOOL85qZiKUQRyT1GKHRU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dArzhztTfAzgMF+lSL3XM/rX1F2TuGX+5hf6dj5Y3bLI7i6Msk8lhYHmNLnHUe+Rr TC8lsSJBwHZ/xyPPnghBrJq7Z6bCmgxT2YQV8zyNhhlz4IjYKUk6QOoYxJvD9NHIzd nuvaVsSlrqUg063oDoqFxOA6pdsOp8PdtEzEd+kw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Ojaswin Mujoo , "Ritesh Harjani (IBM)" , Jan Kara , Theodore Tso , Stefan Wahren Subject: [PATCH 5.15 146/148] ext4: avoid unnecessary spreading of allocations among groups Date: Mon, 26 Sep 2022 12:13:00 +0200 Message-Id: <20220926100801.706278329@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220926100756.074519146@linuxfoundation.org> References: <20220926100756.074519146@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 From: Jan Kara commit 1940265ede6683f6317cba0d428ce6505eaca944 upstream. mb_set_largest_free_order() updates lists containing groups with largest chunk of free space of given order. The way it updates it leads to always moving the group to the tail of the list. Thus allocations looking for free space of given order effectively end up cycling through all groups (and due to initialization in last to first order). This spreads allocations among block groups which reduces performance for rotating disks or low-end flash media. Change mb_set_largest_free_order() to only update lists if the order of the largest free chunk in the group changed. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren Tested-by: Ojaswin Mujoo Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Jan Kara Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/mballoc.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -1080,23 +1080,25 @@ mb_set_largest_free_order(struct super_b struct ext4_sb_info *sbi = EXT4_SB(sb); int i; - if (test_opt2(sb, MB_OPTIMIZE_SCAN) && grp->bb_largest_free_order >= 0) { + for (i = MB_NUM_ORDERS(sb) - 1; i >= 0; i--) + if (grp->bb_counters[i] > 0) + break; + /* No need to move between order lists? */ + if (!test_opt2(sb, MB_OPTIMIZE_SCAN) || + i == grp->bb_largest_free_order) { + grp->bb_largest_free_order = i; + return; + } + + if (grp->bb_largest_free_order >= 0) { write_lock(&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]); list_del_init(&grp->bb_largest_free_order_node); write_unlock(&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]); } - grp->bb_largest_free_order = -1; /* uninit */ - - for (i = MB_NUM_ORDERS(sb) - 1; i >= 0; i--) { - if (grp->bb_counters[i] > 0) { - grp->bb_largest_free_order = i; - break; - } - } - if (test_opt2(sb, MB_OPTIMIZE_SCAN) && - grp->bb_largest_free_order >= 0 && grp->bb_free) { + grp->bb_largest_free_order = i; + if (grp->bb_largest_free_order >= 0 && grp->bb_free) { write_lock(&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]); list_add_tail(&grp->bb_largest_free_order_node,