From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geiger Subject: Re: Degregated I/O Performance since 3.4 - Regression in 3.4? Date: Wed, 25 Apr 2012 01:21:12 +0200 Message-ID: <4F973568.6000002@vido.info> References: <201204231202.27731.tobias.geiger@vido.info> <201204241409.44044.tobias.geiger@vido.info> <201204241607.24864.tobias.geiger@vido.info> <20120424163027.GI3213@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120424163027.GI3213@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xen.org" , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Am 24.04.2012 18:30, schrieb Konrad Rzeszutek Wilk: >>>> I redid the test; >>>> >>>> a) with 3.3.0 kernel >>>> b) with 3.4.0-rc4 >>>> c) with 3.40-rc4 and above patch >>>> >>>> everything else remained the same, i.e. test-program and test-scenario >>>> was not changed and started after about 5min of domu bootup (so that no >>>> strange bootup-effects become relevant); same phy-backend (lvm on ssd), >>>> same everything else; so i cant see what else except the used dom0 >>>> kernel is causing this issue; but here are the numbers: >>>> >>>> a) read: 135mb/s write: 142mb/s >>>> b) read: 39mb/s write: 39mb/s >>>> c) read: 40mb/s write: 40mb/s >>>> >>>> Only thing that may become relevant is the difference in kernel-config >>>> betwen 3.3 and 3.4 - here's the diff : >>>> http://pastebin.com/raw.php?i=Dy71Fegq >>>> >>>> Jan, it seems you're right: The patch doesn't add extra performance >>>> regression - i guess i had an i/o intensive task running in dom0 while >>>> doing the benchmark yesterday, so that the write performance got so bad. >>>> sorry for that. >>>> >>>> Still there's a significant performance penalty from 3.3 to 3.4 >>> Could you please try to revert the following commits? >>> >>> git revert -n a71e23d9925517e609dfcb72b5874f33cdb0d2ad > No way >>> git revert -n 3389bb8bf76180eecaffdfa7dd5b35fa4a2ce9b5 > Startup. >>> git revert -n 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f > Hm, this is just during startup. >>> git revert -n b2167ba6dd89d55ced26a867fad8f0fe388fd595 > No way. > > >>> git revert -n 4f14faaab4ee46a046b6baff85644be199de718c > Perhaps? But I am not seeing it. > >>> git revert -n 9846ff10af12f9e7caac696737db6c990592a74a > Perhaps? >> after reverting said 6 commits (thanks for the ids of these - had difficulties >> to find them), the performance is back to normal. >> >> should i try to circle it down to one of this 6, or do you have a hint on >> which it might be? > I think either off these: 4f14faaab4ee46a046b6baff85644be199de718c > 9846ff10af12f9e7caac696737db6c990592a74a might be the culprit. > > Try the 9846ff10 first. > >> Greetings >> Tobias Hi, 9846ff10 was it! after reverting it, performance returned to normal. Thanks! Tobias