Re: CIK hangs with kernel 3.15, bisected

["Christian König" <deathsimple@vodafone.de>]

Is the performance regression regression caused by the page table 
changes or something else?

I did made some tests with xonotic while developing it and it didn't 
showed anything obvious, but I didn't made tests on different systems.

Christian.

Am 13.05.2014 17:19, schrieb Marek Olšák:
> Your latest patches fix the regression.
>
> The performance regression can also be reproduced with piglit "-t
> texelFetch.fs".
>
> Kernel 3.14:
>     real    0m17.724s
>     user    0m41.905s
>     sys    0m11.299s
>
> The problematic commit checked out + your fixes (without the PTE patch I think):
>     real    0m23.474s
>     user    1m1.008s
>     sys    0m13.812s
>
> Marek
>
>
> On Tue, May 13, 2014 at 3:57 PM, Christian König
> <deathsimple@vodafone.de> wrote:
>> Am 13.05.2014 15:22, schrieb Alex Deucher:
>>
>>> On Mon, May 12, 2014 at 7:38 PM, Grigori Goronzy <greg@chown.ath.cx>
>>> wrote:
>>>> I can confirm this fixes it for me, too.
>>>>
>>>> 3.15 with these fixes and the large PTE patches actually ends up being
>>>> noticeably slower than earlier kernels with Xonotic, though. I wonder
>>>> what's
>>>> going on.
>>> Allocation overhead?
>>
>> Unlikely, Xonotic just allocates a single page table at start, which then
>> gets extended to a certain rate until they no longer need more address space
>> and are done with it.
>>
>> Grigori, can you bisect and/or try to figure out what's wrong here?
>>
>> Christian.
>>
>>
>>>
>>>> Grigori
>>>>
>>>>
>>>> On 12.05.2014 14:50, Christian König wrote:
>>>>> I could reproduce the problem with xonotic and I think I've found the
>>>>> issue.
>>>>>
>>>>> Please test the attached patch.
>>>>>
>>>>> Thanks,
>>>>> Christian.
>>>>>
>>>>> Am 11.05.2014 11:06, schrieb Christian König:
>>>>>>> I have tested it and it doesn't fix the hangs.
>>>>>> Yeah, thought so. Well it was just a guess.
>>>>>>
>>>>>>> (Also, I don't like the patch, because it reverts the behavior I added
>>>>>>> for userspace buffers.)
>>>>>> Actually it shouldn't affect that. The alternative domain always
>>>>>> contains GART even when userspace only specified VRAM as placement (as
>>>>>> long as it is technical possible to do so).
>>>>>>
>>>>>> So what should happen is that TTM sees the current placement, matches
>>>>>> that with the desired placement and should find that it doesn't need
>>>>>> to move the buffer (we should just test if this behavior really works
>>>>>> as expected).
>>>>>>
>>>>>> Christian.
>>>>>>
>>>>>> Am 10.05.2014 23:38, schrieb Marek Olšák:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> I have tested it and it doesn't fix the hangs.
>>>>>>>
>>>>>>> (Also, I don't like the patch, because it reverts the behavior I added
>>>>>>> for userspace buffers.)
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 10, 2014 at 6:34 PM, Christian König
>>>>>>> <deathsimple@vodafone.de> wrote:
>>>>>>>> Couldn't reproduce the issue so far. So the attached patch is just a
>>>>>>>> complete shoot into the dark found by rereading the code, but it
>>>>>>>> might
>>>>>>>> actually be the problem.
>>>>>>>>
>>>>>>>> Please give it a try.
>>>>>>>>
>>>>>>>> Going to keep testing in the meantime,
>>>>>>>> Christian.
>>>>>>>>
>>>>>>>> Am 10.05.2014 10:23, schrieb Christian König:
>>>>>>>>
>>>>>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>>>>>>> I boot
>>>>>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>>>>>>> settings.
>>>>>>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>>>>>>> problem.
>>>>>>>>> Sounds like the same issue to me. Thx for the good test case.
>>>>>>>>>
>>>>>>>>>> Any idea what is wrong with it?
>>>>>>>>> Actually I already wondered that it went so smooth without any
>>>>>>>>> regression
>>>>>>>>> so far, didn't noticed the bug in bugzilla.kernel.org yet.
>>>>>>>>>
>>>>>>>>>> Some of the tests allocate a lot of MSAA textures and the tests
>>>>>>>>>> also
>>>>>>>>>> run in parallel, which creates a lot of memory pressure and
>>>>>>>>>> probably
>>>>>>>>>> causes buffer evictions.
>>>>>>>>> Sounds like the underlying problem to me. We probably evict some
>>>>>>>>> part of a
>>>>>>>>> page table without updating the page directory. Going to dig into
>>>>>>>>> it today,
>>>>>>>>> it's probably just a one liner missing somewhere in the VM code.
>>>>>>>>>
>>>>>>>>> Christian.
>>>>>>>>>
>>>>>>>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy:
>>>>>>>>>> On 09.05.2014 20:03, Marek Olšák wrote:
>>>>>>>>>>>
>>>>>>>>>>> This commit which first appeared in 3.15-rc1 causes hangs on
>>>>>>>>>>> Bonaire:
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>> The simplest way to reproduce the hangs is to run piglit with
>>>>>>>>>>> these
>>>>>>>>>>> parameters:
>>>>>>>>>>> -t texelFetch.fs
>>>>>>>>>>>
>>>>>>>>>>> Some of the tests allocate a lot of MSAA textures and the tests
>>>>>>>>>>> also
>>>>>>>>>>> run in parallel, which creates a lot of memory pressure and
>>>>>>>>>>> probably
>>>>>>>>>>> causes buffer evictions.
>>>>>>>>>>>
>>>>>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>>>>>>> I boot
>>>>>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>>>>>>> settings.
>>>>>>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>>>>>>> problem.
>>>>>>>>>>
>>>>>>>>>> Grigori
>>>>>>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel