[CentOS-devel] Kernel bug fix that restores SSD performance -- testing sought

Thu Jul 18 22:47:10 UTC 2013
Akemi Yagi <amyagi at gmail.com>

On Thu, Jul 18, 2013 at 2:07 PM, Karanbir Singh <mail-lists at 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

> 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 at 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 at 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.