linux-ext4 - [RFC] improve malloc for large filesystems: limit scanning at cr=0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <E1A7B691-30A3-403B-950E-ECD1B86A95A4@whamcloud.com>
Date:   Mon, 2 Dec 2019 08:50:39 +0000
From:   Alex Zhuravlev <azhuravlev@...mcloud.com>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: [RFC] improve malloc for large filesystems: limit scanning at cr=0

Hi,

I refreshed the patches a bit.
So the initial patch is just to limit scanning at cr=0 to initialised groups.
The idea is that scanning at cr=0 is an optimisation on its own - cheap and quick way to find 2^N large chunks.
I think it makes no sense to wait on IO few milliseconds just to skip a group because it’s not perfect.

Thanks, Alex


--- linux-4.18/fs/ext4/mballoc.c	2019-11-28 14:55:26.500545920 +0300
+++ linux-4.18/fs/ext4/mballoc.c	2019-11-28 14:53:18.600086008 +0300
@@ -2060,7 +2060,15 @@ static int ext4_mb_good_group(struct
 
 	/* We only do this if the grp has never been initialized */
 	if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
-		int ret = ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
+		int ret;
+
+		/* cr=0 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 == 0)
+			return 0;
+		ret = ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
 		if (ret)
 			return ret;
 	}