According to this bug report:
http://bugs.centos.org/view.php?id=6548 (originally from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642729 )
a patch introduced in kernel 2.6.32 causes a performance drop in [certain] SSDs. This patch was later reverted in the mainline kernel. With this kernel, the reporter says, the SSD performance is now what is expected from the spec.
I have built a centosplus kernel that has the referenced patch reverted. My limited test (using hdparm) did show some improvement with this kernel. kernel-ml from ELRepo (currently at 3.10.0-1.el6) gave a number similar to this plus kernel.
http://people.centos.org/toracat/kernel/6/plus/bug6548/
Please test if you can and report back with your findings (good, bad, no diff ...). Note that the packages are not signed and are provided for testing purposes only.
Thanks in advance for your input.
Akemi / toracat
On 07/14/2013 07:49 PM, Akemi Yagi wrote:
Please test if you can and report back with your findings (good, bad, no diff ...). Note that the packages are not signed and are provided for testing purposes only.
on a dell R420, 4x500gb sata platters -> no diff in perf ( using iozone )
on the same machine, with the disks replaced with a 128gb Crucial M4 ssd, again no difference in perf with iozone between this kernel and the distro kernel.
Which then has me thinking - what is the actual problem we are trying to solve here ? and how can I ratify that ?
- KB
On Thu, Jul 18, 2013 at 5:07 PM, Karanbir Singh mail-lists@karan.org wrote:
On 07/14/2013 07:49 PM, Akemi Yagi wrote:
Please test if you can and report back with your findings (good, bad, no diff ...). Note that the packages are not signed and are provided for testing purposes only.
on a dell R420, 4x500gb sata platters -> no diff in perf ( using iozone )
on the same machine, with the disks replaced with a 128gb Crucial M4 ssd, again no difference in perf with iozone between this kernel and the distro kernel.
Which then has me thinking - what is the actual problem we are trying to solve here ? and how can I ratify that ?
Also, is this related to SSD trim support?
- KB
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jul 18, 2013 at 2:07 PM, Karanbir Singh mail-lists@karan.org wrote:
On 07/14/2013 07:49 PM, Akemi Yagi wrote:
Please test if you can and report back with your findings (good, bad, no diff ...). Note that the packages are not signed and are provided for testing purposes only.
on a dell R420, 4x500gb sata platters -> no diff in perf ( using iozone )
on the same machine, with the disks replaced with a 128gb Crucial M4 ssd, again no difference in perf with iozone between this kernel and the distro kernel.
Thanks for doing the test. It is possible that that particular SSD is not affected. It's best if we can collect data from a variety of models.
Which then has me thinking - what is the actual problem we are trying to solve here ? and how can I ratify that ?
All details are given in CentOS bug #6548 (links therein) but here's is a short summary of the events that were seen in the kernel development [list].
Someone reported "bad performance with SSD since kernel version 2.6.32". After bisection, he found the following commit to be the likely culprit:
commit fb1e75389bd06fd5987e9cda1b4e0305c782f854 Author: Jens Axboe jens.axboe@xxxxxxxxxx Date: Thu Jul 30 08:18:24 2009 +0200 (This was added to kernel 2.6.32)
Long story short, this commit was reverted in kernel 2.6.33:
commit 79da0644a8e0838522828f106e4049639eea6baf Author: Jens Axboe jens.axboe@oracle.com Date: Tue Feb 23 08:40:43 2010 +0100
Now, the CentOS-6 kernel does have the original commit but not the second (revertant) one. Therefore, it is possible that the SSD performance with C6 is worse than what is expected from their specifications. And this can be tested by comparing the CentOS kernel 'before' and 'after' reverting the 2.6.32 patch in question.
The question we are asking is whether or not the 'after' kernel actually reinstates the performance of pre-2.6.32. If the performance turns out to be better with the 'after' kernel, that means that the tested SSD is indeed affected by the 2.6.32 patch like the one reported by the submitter.
Akemi
On Thu, Jul 18, 2013 at 3:47 PM, Akemi Yagi amyagi@gmail.com wrote:
On Thu, Jul 18, 2013 at 2:07 PM, Karanbir Singh mail-lists@karan.org wrote:
Which then has me thinking - what is the actual problem we are trying to solve here ? and how can I ratify that ?
All details are given in CentOS bug #6548 (links therein) but here's is a short summary of the events that were seen in the kernel development [list].
Someone reported "bad performance with SSD since kernel version 2.6.32". After bisection, he found the following commit to be the likely culprit:
commit fb1e75389bd06fd5987e9cda1b4e0305c782f854 Author: Jens Axboe jens.axboe@xxxxxxxxxx Date: Thu Jul 30 08:18:24 2009 +0200 (This was added to kernel 2.6.32)
Long story short, this commit was reverted in kernel 2.6.33:
commit 79da0644a8e0838522828f106e4049639eea6baf Author: Jens Axboe jens.axboe@oracle.com Date: Tue Feb 23 08:40:43 2010 +0100
(snip)
Just wanted to update the status of the issue.
(1) Current centosplus kernel 2.6.32-358.18.1.el6.centos.plus has the patch from the second commit quoted above that is supposed to rectify the issue.
(2) I've filed a bug report upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1003678 (It's marked private)
From the way it looks, the patch will be pulled in to the RHEL kernel
but no specific version is given.
Akemi
-
Akemi Yagi -
Karanbir Singh -
Mauricio Tavares