You are not logged in.
As 2.6.32 approaches, i'd like to post the Phoronix benchmarks for it
http://www.phoronix.com/scan.php?page=a … arks&num=1
There seems to be a "large" performance loss on ext4 due to a specific commit on main kernel branch.
http://www.phoronix.com/scan.php?page=a … ions&num=2
http://git.kernel.org/?p=linux/kernel/g … 25b9aeb745
I'd like to ask if it is possible to have .32 kernel with a patch that would revert that upstream commit.
If that isn't allowed by Arch patching policy, just ignore this thread
Offline
As 2.6.32 approaches, i'd like to post the Phoronix benchmarks for it
http://www.phoronix.com/scan.php?page=a … arks&num=1
There seems to be a "large" performance loss on ext4 due to a specific commit on main kernel branch.
http://www.phoronix.com/scan.php?page=a … ions&num=2
http://git.kernel.org/?p=linux/kernel/g … 25b9aeb745
I'd like to ask if it is possible to have .32 kernel with a patch that would revert that upstream commit.
If that isn't allowed by Arch patching policy, just ignore this thread
http://wiki.archlinux.org/index.php/Dev … i:Patching
i think kernel developers know better what the hell is going in there and should be trusted no?
Last edited by wonder (2009-11-28 10:01:45)
Give what you have. To someone, it may be better than you dare to think.
Offline
From the git commit:
We need to flush the write cache unconditionally in ->fsync, otherwise
writes into already allocated blocks can get lost.
Do you really want performance, even at the risk of data loss?
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
The right way to approach this is to run a comparison yourself using the latest 2.6.32 rc and report the regression on the kernel's bugzilla. That way the right people are informed about it and can decide what to do with it.
Offline
@tomk: Can you provide a reliable benchmark that I could use ? I currently have both .31 and .32-rc8 installed, I could make a test.
Offline
You could try IOzone, available in AUR http://aur.archlinux.org/packages.php?ID=22212
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
Nathaniel Borenstein
Offline
I would say that bonnie++ would fit the bill quite well.
Offline
You could try IOzone, available in AUR http://aur.archlinux.org/packages.php?ID=22212
How can I use it ? man page is full of options.
Trying bonnie++ right now.
Last edited by flamelab (2009-11-28 10:34:16)
Offline
tverdok wrote:You could try IOzone, available in AUR http://aur.archlinux.org/packages.php?ID=22212
How can I use it ? man page is full of options.
Trying bonnie++ right now.
If you decide to use Iozone, just go with automatic mod Iozone -a
I'm not really familiar with bonnie++, so can't help you there.
EDIT: Here is a guide in pdf format http://www.iozone.org/docs/IOzone_msword_98.pdf
Last edited by tverdok (2009-11-28 10:47:44)
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
Nathaniel Borenstein
Offline
bonnie++ in main Arch packages is extremely old, I recommend the rock-stable 'experimental' package: http://aur.archlinux.org/packages.php?ID=24114
Offline
Eric Sandeen's explanation: http://www.phoronix.com/scan.php?page=a … ions&num=2
Offline
Eric Sandeen's explanation: http://www.phoronix.com/scan.php?page=a … ions&num=2
Very nice! They even tracked down the cause of the performance drop.
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
Nathaniel Borenstein
Offline
Bonnie++ from AUR:
System: Intel Core i5 750, 4GB of RAM, WD6401AALS
2.6.31
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
flamepc 8G 723 97 82719 7 39984 4 4192 98 106395 4 385.7 4
Latency 11481us 943ms 265ms 2472us 11436us 306ms
Version 1.96 ------Sequential Create------ --------Random Create--------
flamepc -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 24965 33 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 11731us 422us 437us 112us 82us 81us
1.96,1.96,flamepc,1,1259401928,8G,,723,97,82719,7,39984,4,4192,98,106395,4,385.7,4,16,,,,,24965,33,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,11481us,943ms,265ms,2472us,11436us,306ms,11731us,422us,437us,112us,82us,81us
2.6.32
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
flamepc 8G 822 98 81669 7 38687 3 4198 75 105470 4 255.0 3
Latency 11138us 1600ms 1302ms 74131us 52760us 573ms
Version 1.96 ------Sequential Create------ --------Random Create--------
flamepc -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 129us 402us 411us 184us 62us 51us
1.96,1.96,flamepc,1,1259395151,8G,,822,98,81669,7,38687,3,4198,75,105470,4,255.0,3,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,11138us,1600ms,1302ms,74131us,52760us,573ms,129us,402us,411us,184us,62us,51us
I just ran bonnie++ executable, with no options.
I'll try the ozone benchmark now. [edit] iozone -a has a non-readable output hmmm.
Last edited by flamelab (2009-11-28 11:04:42)
Offline
Try Iozone -g 4G -Rab [outputfile.wks]
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
Nathaniel Borenstein
Offline
If you know you have no write cache, or that it is safely battery backed, then you can mount with -o nobarrier, and not incur this penalty.
Is this what you want?
But like B says, if they changed it they have a good reason. everyone wants a filesystem that is as fast as possible but data loss is not acceptable at all.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
well ok we will wait for Btrfs and maybe that will be even more speedy. I want a fast filesystem but data loss would not be very nice and it would NOT be professional of the linux kernel devs to ignore it because tweaking would make the filesystem slightly slower.
By the way flamelab, nice blog.
Offline
I haven't tried yet Btrfs, but from what I see, it has a LOT of potential.
-----
As for the performance regression: it is "eliminated" with barrier=0. But you seriously need to have a UPS then to prevent data loss, especially if you have a lot of data transferred or used or opened to be used.
-------
@bananaoomarang: Thanks
Offline
Does ext4 is still faster than ext3 ?
Offline
Ext4 became a bit slower in favor of data integrity but the other advantages of ext4 over ext3 still remain, such as faster volume checking if I'm not mistaken (that alone is a big plus for me, checking 100GB ext3 partitions on a notebook can take a good while).
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
yeah it's still faster just by a little less than it was before.
Offline