Hello,
last week we received new machines (DELL R720xd) for an extension of our
ceph cluster.
(64 Gb ram, 2x Xeon E5-2650, PERC H710P (really LSI MEGARAID), and 12x3
TB disks + 2SSD (not used as cachecade))
I was doing test on the raid card with kernel 3.4.38 to try to find what
I can get of this beast with RAID5, when I noticed an unusual slow
values on compilebench. The difference is very visible on the initial
create tests (can detail more if needed).
I finally observed that ONLY 3.4 kernels exhibit that behaviour ;
3.3.xxx and before are OK, 3.5.xxx and later are back to good values.
I bisected the problem to this commit
c999a223c2f0d31c64ef7379814cea1378b2b800 is the first bad commit
commit c999a223c2f0d31c64ef7379814cea1378b2b800
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Thu Mar 22 05:15:07 2012 +0000
xfs: introduce an allocation workqueue
I understand this regression is not a bug, and probably just a corner
case of the new code, that was certainly corrected after during 3.5
development (didn't tried to bisect this one, maybe dave know what is
the corrective patch ?)
The problem is that 3.4 is the last long-term kernel for the moment, and
it's unfortunate it shows this regression.
Maybe a backport of the fix (if this backport is possible AND not very
intrusive) could be a good idea ?
Cheers,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@xxxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
