linux-kernel - ext2/3/4 performance issue

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 10 May 2015 10:01:09 +0200
From:	Bernhard Kraft <kraftb@...nk-open.at>
To:	linux-kernel@...r.kernel.org
Subject: ext2/3/4 performance issue

Hello folks,

I work on implementing the ext2 filesystem for a PIC microcontroller and 
while reading the sources of it in the linux kernel I stumbled upon the 
following performance issue. I don't know if it is really important but 
I tought I will ask:

In super.c in function "ext2_statfs" there is a for loop [1] which 
iterates over all block groups to determine the overhead each block 
group has. For this it determines if the block group has a superblock 
(by calling "ext2_bg_has_super") and how many blocks are occupied by the 
group descriptor blocks (by calling "ext2_bg_num_gdb").

Now it is the case, that "ext2_bg_num_gdb" itself calls 
"ext2_bg_has_super" in balloc.c [2]. See ext2_bg_num_gdb at the very 
bottom of balloc.c

There will only be a group descriptor if there is a superblock. The 
overhead generated by calling "ext2_bg_has_super" twice is not quite 
minimal. At least if the sparse superblock feature is used as it 
involves checking if the block number equals any power of 3, 5 or 7.

So as every block which has a superblock must also have a group 
descriptor it would be fine to replace the for loop mentioned in [1] by 
a for loop like:

------------ snip -------------------
for (i = 0; i < sbi->s_groups_count; i++)
	if (ext2_bg_has_super(sb, i))
		overhead += 1 + sbi->s_gdb_count;
------------ snip -------------------

The call to "ext_bg_num_gb" is avoided an by this the redundant call to 
"ext2_bg_has_super". As the function isn't used anywhere else it could 
get removed at all.

I don't know if "ext2_statfs" is called often enough that such an 
optimization would make sense. And I am also not involved in kernel 
development so I am not quite into kernel coding guidelines.

The same issue is also valid for ext3 and ext4.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/ext2/super.c#n1395

[2] 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/ext2/balloc.c#n1532

greetings,
Bernhard
-- 
Wer nicht gelegentlich auch einmal kausalwidrige Dinge zu denken vermag,
wird seine Wissenschaft nie um eine neue Idee bereichern können.
Max Planck (1858-1947)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/