Re: Degregated I/O Performance since 3.4 - Regression in 3.4?

[Tobias Geiger <tobias.geiger@vido.info>]

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