Re: [PATCH 2/9] sector_t format string

[Andrew Morton]

On Thu, 10 Aug 2006 12:24:06 -0400
"John Stoffel" <john@xxxxxxxxxxx> wrote:

> >>>>> "Roman" == Roman Zippel <zippel@xxxxxxxxxxxxxx> writes:
> 
> Roman> If you force everyone to use 64bit sector numbers, I don't
> Roman> understand how you can claim "still working just fine on
> Roman> 32bit"?  At some point ext4 is probably going to be the de
> Roman> facto standard, which very many people want to use, because it
> Roman> has all the new features, which won't be ported to ext2/3. So I
> Roman> still don't understand, what's so wrong about a little tuning
> Roman> in both directions?
> 
> The problem as I see it, is that you want extents, but you don't want
> the RAM/DISK/ROM penalty of 64bit blocks, since embedded devices won't
> ever go past the existing ext3 sizes, right?

For ext3 on x86:

CONFIG_LBD=y:

box:/usr/src/25> size fs/jbd/jbd.o fs/ext3/ext3.o
   text    data     bss     dec     hex filename
  51076       8      32   51116    c7ac fs/jbd/jbd.o
  87466    1020       4   88490   159aa fs/ext3/ext3.o

CONFIG_LBD=n:

box:/usr/src/25> size fs/jbd/jbd.o fs/ext3/ext3.o
   text    data     bss     dec     hex filename
  51133       8      32   51173    c7e5 fs/jbd/jbd.o
  87679    1020       4   88703   15a7f fs/ext3/ext3.o

That's a grand total of 270 bytes of text saved.  aka 0.19%.

We'll save four bytes in the inode (unlikely to save anything due to slab
packing).

We'll save 12 bytes against open-for-writing files due to
ext3_block_alloc_info shrinkage (unlikely to save anything due to kmalloc
size roundup).

IOW, unless I've missed something major, we're looking at a total saving of
around a 16th of a page.  We can save more than that any day of the week by
going around and deleting some crap from somewhere.  We can surely save
more than this by taming ext4's inlining frenzy.

I'd expect any runtime savings to be similarly modest.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/