Sorry about the confusing email before. This should make more sense =)
These results compare EXT3 against EXT2 with rmap using the contest tool
you can get it at: http://contest.kolivas.net
These tests are from a Athlon MP 2000+ w/ 512MB RAM
noload:
Kernel Time CPU
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 259.47 99%
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 267.66 97%
process_load:
Kernel Time CPU
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 318.91 80%
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 324.44 79%
io_halfmem:
Kernel Time CPU
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 306.82 87%
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 461.74 57%
io full mem:
Kernel Time CPU
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 325.39 82%
2.4.20-pre7-rmap14a-xfs-uml-shawn12d 411.47 64%
full logs of the tests are:
WITH EXT2
------------
noload Time: 259.47 CPU: 99% Major Faults: 770937 Minor Faults: 1173705
process_load Time: 318.91 CPU: 80% Major Faults: 742261 Minor Faults:
1169516
io_halfmem Time: 306.82 CPU: 87% Major Faults: 742000 Minor Faults: 1169497
Was writing number 33 of a 257Mb sized io_load file after 307 seconds
io_fullmem Time: 325.39 CPU: 82% Major Faults: 742000 Minor Faults: 1169494
Was writing number 16 of a 514Mb sized io_load file after 337 seconds
mem_load Time: 340.32 CPU: 79% Major Faults: 743307 Minor Faults: 1170011
WITH EXT3
-----------
noload Time: 267.66 CPU: 97% Major Faults: 771111 Minor Faults: 1173722
process_load Time: 324.44 CPU: 79% Major Faults: 742261 Minor Faults:
1169518
io_halfmem Time: 461.74 CPU: 57% Major Faults: 742000 Minor Faults: 1169496
Was writing number 34 of a 257Mb sized io_load file after 465 seconds
io_fullmem Time: 411.47 CPU: 64% Major Faults: 742000 Minor Faults: 1169494
Was writing number 15 of a 514Mb sized io_load file after 425 seconds
mem_load Time: 333.99 CPU: 81% Major Faults: 743320 Minor Faults: 1170021
NOTES:
====
As you can see, there's something DEFINATELY wrong here. EXT3 is much slower
then EXT2. I converted the EXT3 disk back to EXT2 to do the second test.
Also, I specified no mount options for EXT3 (which means it uses ordered
mode). The journal was created with tune2fs -j /dev/hda#
>From #Kernelnewbies (snip)
==============
<ShawnCONSOLE> riel uses EXT3
<riel> my cpu is slower
<ShawnCONSOLE> but you have fast disks?
<riel> so it doesn't fall idle as quickly as yours, when waiting on the disk
<riel> not very fast ;)
<riel> old 8 GB IDE disk
<ShawnCONSOLE> so having a fast disk and a fast CPU causes the cpu to wait
longer cause the disk finishes its tasks much faster then the cpu expects?
<ShawnCONSOLE> mem load final test = 78%
<ShawnCONSOLE> so final numbers:
<ShawnCONSOLE> 99, 80%, 87%, 83%, 75%
<riel> yes, a very fast CPU falls idle more quickly
<riel> but it's very curious that ext3 is that much worse than ext2
<ShawnCONSOLE> thats much better.
<riel> definately worth pointing out to the ext3 maintainers.
Legend:
Kernel Time CPU
2.4.20-pre7-rmap14a-xfs-uml-shawn12d(EXT2)
2.4.20-pre7-rmap14a-xfs-uml-shawn12d(EXT3)
On September 19, 2002 12:16 am, Shawn Starr wrote:
> Sorry about the confusing email before. This should make more sense =)
>
> These results compare EXT3 against EXT2 with rmap using the contest tool
> you can get it at: http://contest.kolivas.net
>
> These tests are from a Athlon MP 2000+ w/ 512MB RAM
>
> noload:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 259.47 99%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 267.66 97%
>
> process load:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 318.91 80%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 324.44 79%
>
> io halfmem:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 306.82 87%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 461.74 57%
>
> io full mem:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 325.39 82%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 411.47 64%
>
> full logs of the tests are:
>
> WITH EXT2
> ------------
> noload Time: 259.47 CPU: 99% Major Faults: 770937 Minor Faults: 1173705
> process load Time: 318.91 CPU: 80% Major Faults: 742261 Minor Faults:
> 1169516
> io halfmem Time: 306.82 CPU: 87% Major Faults: 742000 Minor Faults:
> 1169497 Was writing number 33 of a 257Mb sized io load file after 307
> seconds io fullmem Time: 325.39 CPU: 82% Major Faults: 742000 Minor
> Faults: 1169494 Was writing number 16 of a 514Mb sized io load file after
> 337 seconds mem load Time: 340.32 CPU: 79% Major Faults: 743307 Minor
> Faults: 1170011
>
>
> WITH EXT3
> -----------
>
> noload Time: 267.66 CPU: 97% Major Faults: 771111 Minor Faults: 1173722
> process load Time: 324.44 CPU: 79% Major Faults: 742261 Minor Faults:
> 1169518
> io halfmem Time: 461.74 CPU: 57% Major Faults: 742000 Minor Faults:
> 1169496 Was writing number 34 of a 257Mb sized io load file after 465
> seconds io fullmem Time: 411.47 CPU: 64% Major Faults: 742000 Minor
> Faults: 1169494 Was writing number 15 of a 514Mb sized io load file after
> 425 seconds mem load Time: 333.99 CPU: 81% Major Faults: 743320 Minor
> Faults: 1170021
>
> NOTES:
> ====
>
> As you can see, there's something DEFINATELY wrong here. EXT3 is much
> slower then EXT2. I converted the EXT3 disk back to EXT2 to do the second
> test.
>
> Also, I specified no mount options for EXT3 (which means it uses ordered
> mode). The journal was created with tune2fs -j /dev/hda#
>
>
> From #Kernelnewbies (snip)
> ==============
> <ShawnCONSOLE> riel uses EXT3
> <riel> my cpu is slower
> <ShawnCONSOLE> but you have fast disks?
> <riel> so it doesn't fall idle as quickly as yours, when waiting on the
> disk <riel> not very fast ;)
> <riel> old 8 GB IDE disk
> <ShawnCONSOLE> so having a fast disk and a fast CPU causes the cpu to wait
> longer cause the disk finishes its tasks much faster then the cpu expects?
> <ShawnCONSOLE> mem load final test = 78%
> <ShawnCONSOLE> so final numbers:
> <ShawnCONSOLE> 99, 80%, 87%, 83%, 75%
> <riel> yes, a very fast CPU falls idle more quickly
> <riel> but it's very curious that ext3 is that much worse than ext2
> <ShawnCONSOLE> thats much better.
> <riel> definately worth pointing out to the ext3 maintainers.
On Sep 19, 2002 00:16 -0400, Shawn Starr wrote:
> These results compare EXT3 against EXT2 with rmap using the contest tool
> you can get it at: http://contest.kolivas.net
>
> These tests are from a Athlon MP 2000+ w/ 512MB RAM
>
> noload:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 259.47 99%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 267.66 97%
>
> process_load:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 318.91 80%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 324.44 79%
>
> io_halfmem:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 306.82 87%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 461.74 57%
>
> io full mem:
>
> Kernel Time CPU
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 325.39 82%
> 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 411.47 64%
I don't see this as hugely surprising. ext3 uses more CPU than ext2.
If you are using up the CPU doing other things, then naturally ext3
will take a longer wall-clock time to complete the same tasks as ext2.
I know that Andrew has been doing a bunch of work to reduce ext3 CPU
usage/locking/etc., but I think that is all in 2.5 kernels.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Well, all the tests were done in single user mode =)
On September 19, 2002 02:13 am, Andreas Dilger wrote:
> On Sep 19, 2002 00:16 -0400, Shawn Starr wrote:
> > These results compare EXT3 against EXT2 with rmap using the contest tool
> > you can get it at: http://contest.kolivas.net
> >
> > These tests are from a Athlon MP 2000+ w/ 512MB RAM
> >
> > noload:
> >
> > Kernel Time CPU
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 259.47 99%
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 267.66 97%
> >
> > process_load:
> >
> > Kernel Time CPU
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 318.91 80%
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 324.44 79%
> >
> > io_halfmem:
> >
> > Kernel Time CPU
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 306.82 87%
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 461.74 57%
> >
> > io full mem:
> >
> > Kernel Time CPU
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 325.39 82%
> > 2.4.20-pre7-rmap14a-xfs-uml-shawn12d 411.47 64%
>
> I don't see this as hugely surprising. ext3 uses more CPU than ext2.
> If you are using up the CPU doing other things, then naturally ext3
> will take a longer wall-clock time to complete the same tasks as ext2.
>
> I know that Andrew has been doing a bunch of work to reduce ext3 CPU
> usage/locking/etc., but I think that is all in 2.5 kernels.
>
> Cheers, Andreas
> --
> Andreas Dilger
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> http://sourceforge.net/projects/ext2resize/
Hi,
On Mon, Sep 23, 2002 at 04:00:03PM -0400, Shawn Starr wrote:
> Which branch of the kernel is this going into? an -ac branch or 2.5 bk?
Ext3 CVS, but I'll also make a clean, broken-down patchset for
2.4.19 bk.
In fact, the only reason it's not in ext3 cvs already is because it's
such a pain keeping discrete broken-down patches separate using a form
of SCM like bk or cvs; having decent scripts to track multiple patches
in a working source tree just works a lot better for one developer
when it comes to merging stuff upstream.
Cheers,
Stephen