xfs
[Top] [All Lists]

kernels 3.4 slower due to allocation workqueue

To: xfs@xxxxxxxxxxx
Subject: kernels 3.4 slower due to allocation workqueue
From: Yann Dupont <Yann.Dupont@xxxxxxxxxxxxxx>
Date: Mon, 15 Apr 2013 11:39:26 +0200
Delivered-to: xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
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

<Prev in Thread] Current Thread [Next in Thread>