Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Alex Zhuravlev <azhuravlev@whamcloud.com>
To:     "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: [PATCH 2/2] ext4: skip non-loaded groups at cr=0/1
Thread-Topic: [PATCH 2/2] ext4: skip non-loaded groups at cr=0/1
Thread-Index: AQHWHEjMB7oRIPFrfU+3AQZmsRdo/g==
Date:   Mon, 27 Apr 2020 04:03:24 +0000
Message-ID: <0B6BF408-EDF7-4363-80CD-BDA0136BF62C@whamcloud.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: whamcloud.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F2803DC2CCF1EE42A899F99553D06E06@namprd19.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c5331e79-b4e9-4f23-dc1f-08d7ea5feefa
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 04:03:24.7095
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 753b6e26-6fd3-43e6-8248-3f1735d59bb4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9rTrQ6n4q+yNA2NRTq/e5OTXS55yBsVcWOkBl86HYxn3L7BtE1962dzDP+1rBOp/W0Z3fSUqGW6Nqufa3hHW5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB2363
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-ext4.vger.kernel.org>
X-Mailing-List: linux-ext4@vger.kernel.org

Hi, yet another patch.

cr=3D0 is supposed to be an optimization to save CPU cycles, but if buddy d=
ata (in memory)
is not initialized then all this makes no sense as we have to do sync IO ta=
king a lot of cycles.
also, at cr=3D0 mballoc doesn't store any avaibale chunk. cr=3D1 also skips=
 groups using heuristic
based on avg. fragment size. it's more useful to skip such groups and switc=
h to cr=3D2 where
groups will be scanned for available chunks.

using sparse image and dm-slow virtual device of 120TB was simulated. then =
the image was
formatted and filled using debugfs to mark ~85% of available space as busy.=
 mount process w/o
the patch couldn't complete in half an hour (according to vmstat it would t=
ake ~10-11 hours).
with the patch applied mount took ~20 seconds.

Lustre-bug-id: https://jira.whamcloud.com/browse/LU-12988
Signed-off-by: Alex Zhuravlev <bzzz@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
---
 fs/ext4/mballoc.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index e84c298e739b..83e3e6ab1240 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1877,6 +1877,21 @@ int ext4_mb_find_by_goal(struct ext4_allocation_cont=
ext *ac,
 	return 0;
 }
=20
+static inline int ext4_mb_uninit_on_disk(struct super_block *sb,
+				    ext4_group_t group)
+{
+	struct ext4_group_desc *desc;
+
+	if (!ext4_has_group_desc_csum(sb))
+		return 0;
+
+	desc =3D ext4_get_group_desc(sb, group, NULL);
+	if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))
+		return 1;
+
+	return 0;
+}
+
 /*
  * The routine scans buddy structures (not bitmap!) from given order
  * to max order and tries to find big enough chunk to satisfy the req
@@ -2060,7 +2075,15 @@ static int ext4_mb_good_group(struct ext4_allocation=
_context *ac,
=20
 	/* We only do this if the grp has never been initialized */
 	if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
-		int ret =3D ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
+		int ret;
+
+		/* cr=3D0/1 is a very optimistic search to find large
+		 * good chunks almost for free. if buddy data is
+		 * not ready, then this optimization makes no sense */
+
+		if (cr < 2 && !ext4_mb_uninit_on_disk(ac->ac_sb, group))
+			return 0;
+		ret =3D ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
 		if (ret)
 			return ret;
 	}
--=20