linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ext2/3/4 performance issue
@ 2015-05-10  8:01 Bernhard Kraft
  2015-05-10 21:56 ` Theodore Ts'o
  0 siblings, 1 reply; 2+ messages in thread
From: Bernhard Kraft @ 2015-05-10  8:01 UTC (permalink / raw)
  To: linux-kernel

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)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ext2/3/4 performance issue
  2015-05-10  8:01 ext2/3/4 performance issue Bernhard Kraft
@ 2015-05-10 21:56 ` Theodore Ts'o
  0 siblings, 0 replies; 2+ messages in thread
From: Theodore Ts'o @ 2015-05-10 21:56 UTC (permalink / raw)
  To: Bernhard Kraft; +Cc: linux-kernel

On Sun, May 10, 2015 at 10:01:09AM +0200, Bernhard Kraft wrote:
> 
> 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.....

Your observations are currect as far as ext2 is concerned; by the time
you get to ext4, it's a bit more complicated.  Also, the
extN_bg_has_super() has in general not been a bottleneck, at least on
modern CPUs.  Perhaps it would be more of an issue on a PIC
microcontroller, of course.

Finally, note that the overhead is cached so it is only calculated the
first time the extN_statfs() is called.

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-05-10 21:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-10  8:01 ext2/3/4 performance issue Bernhard Kraft
2015-05-10 21:56 ` Theodore Ts'o

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).