dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Grigori Goronzy <greg@chown.ath.cx>
To: "Marek Olšák" <maraeo@gmail.com>,
	"Christian König" <deathsimple@vodafone.de>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: CIK hangs with kernel 3.15, bisected
Date: Tue, 13 May 2014 22:19:30 +0200	[thread overview]
Message-ID: <53727E52.20502@chown.ath.cx> (raw)
In-Reply-To: <CAAxE2A5cytbn0JpKjvV0S5-nT3Y38q=uS=_ANpLqw_ryh4_EOA@mail.gmail.com>

On 13.05.2014 21:50, Marek Olšák wrote:
> Hi Christian,
>
> The performance regression I saw with piglit seems to be fixed with
> latest kernel git. It's difficult to bisect the kernel, because there
> are only merges between 3.14 and 3.15 and the merged committs are
> actually based on 3.14-rc1 and 3.14-rc4.
>
> All seems to be fine with your fixes.
>

Which fixes have you applied? There are quite a few pending patches on 
dri-devel, that aren't yet part of drm-fixes-3.15.

Grigori

> Marek
>
> On Tue, May 13, 2014 at 5:31 PM, Christian König
> <deathsimple@vodafone.de> wrote:
>> 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
>>>>
>>>>
>>

  reply	other threads:[~2014-05-13 20:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 18:03 CIK hangs with kernel 3.15, bisected Marek Olšák
2014-05-09 18:10 ` Rafał Miłecki
2014-05-09 21:39 ` Grigori Goronzy
2014-05-10  8:23   ` Christian König
2014-05-10 16:34     ` Christian König
2014-05-10 21:38       ` Marek Olšák
2014-05-11  9:06         ` Christian König
2014-05-12 12:50           ` Christian König
2014-05-12 23:38             ` Grigori Goronzy
2014-05-13 13:22               ` Alex Deucher
2014-05-13 13:57                 ` Christian König
2014-05-13 15:19                   ` Marek Olšák
2014-05-13 15:31                     ` Christian König
2014-05-13 16:08                       ` Marek Olšák
2014-05-13 19:50                       ` Marek Olšák
2014-05-13 20:19                         ` Grigori Goronzy [this message]
2014-05-13 20:27                           ` Marek Olšák
2014-05-30  0:30                             ` Grigori Goronzy
2014-05-30 11:30                               ` Marek Olšák
2014-05-30 11:46                                 ` Grigori Goronzy
2014-05-30 11:51                                   ` Marek Olšák
2014-05-30 18:01                                   ` Grigori Goronzy
2014-05-13 21:21 ` Marek Olšák
2014-05-14 12:11   ` Christian König
2014-05-27 21:55     ` Marek Olšák
2014-05-28 10:38       ` Christian König
2014-05-29 16:30         ` Christian König
2014-05-29 16:51           ` Marek Olšák
2014-05-29 16:59             ` Christian König
2014-05-29 16:52           ` Alex Deucher
2014-05-30 15:57             ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53727E52.20502@chown.ath.cx \
    --to=greg@chown.ath.cx \
    --cc=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox