lkml.org 
[lkml]   [2002]   [Sep]   [19]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromShawn Starr <>
SubjectRe: [BENCHMARK] EXT3 vs EXT2 results with rmap14a and testing with contest 0.34
DateThu, 19 Sep 2002 00:21:21 -0400
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:29    [from the cache]
©2003-2008