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