kernels 3.4 slower due to allocation workqueue

[Yann Dupont <Yann.Dupont@univ-nantes.fr>]

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@redhat.com>
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@univ-nantes.fr

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs