From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
"Tobias Klausmann" <tobias.johannes.klausmann@mni.thm.de>,
"Mike Galbraith" <efault@gmx.de>
Cc: nouveau <nouveau@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Ben Skeggs <bskeggs@redhat.com>
Subject: Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
Date: Tue, 19 Dec 2017 14:45:05 +0100 [thread overview]
Message-ID: <e1b8dd62-4423-2b51-9634-e8938801b5d9@gmail.com> (raw)
In-Reply-To: <a96f755f-a20b-a177-ead1-7b79acbb1250@daenzer.net>
Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
> On 2017-12-19 11:37 AM, Michel Dänzer wrote:
>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:
>>> On 12/18/17 7:06 PM, Mike Galbraith wrote:
>>>> Greetings,
>>>>
>>>> Kernel bound workloads seem to trigger the below for whatever reason.
>>>> I only see this when beating up NFS. There was a kworker wakeup
>>>> latency issue, but with a bandaid applied to fix that up, I can still
>>>> trigger this.
>>>
>>> Hi,
>>>
>>> i have seen this one as well with my system, but i could not find an
>>> easy way to trigger it for bisecting purpose. If you can trigger it
>>> conveniently, a bisect would be nice!
>> I'm seeing this (with the amdgpu and radeon drivers) when restic takes a
>> backup, creating memory pressure. I happen to have just finished
>> bisecting, the result is:
>>
>> 648bc3574716400acc06f99915815f80d9563783 is the first bad commit
>> commit 648bc3574716400acc06f99915815f80d9563783
>> Author: Christian König <christian.koenig@amd.com>
>> Date: Thu Jul 6 09:59:43 2017 +0200
>>
>> drm/ttm: add transparent huge page support for DMA allocations v2
>>
>> Try to allocate huge pages when it makes sense.
>>
>> v2: fix comment and use ifdef
>>
>>
> BTW, I haven't noticed any bad effects other than the dmesg splats, so
> maybe it's just noise about transient failures for which there is a
> proper fallback in place.
Yeah, I think that is exactly what happens here.
We try to allocate a huge page, but fail and so fall back to using
multiple 4k pages instead.
Going to send out a patch to suppress the warning.
Thanks for bisecting this,
Christian.
next prev parent reply other threads:[~2017-12-19 13:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 18:06 nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 Mike Galbraith
2017-12-18 19:01 ` Tobias Klausmann
2017-12-18 19:12 ` Mike Galbraith
2017-12-19 10:37 ` Michel Dänzer
2017-12-19 10:39 ` Michel Dänzer
2017-12-19 13:45 ` Christian König [this message]
2017-12-31 18:27 ` Ilia Mirkin
2017-12-31 20:53 ` Mike Galbraith
2018-01-01 18:08 ` Ilia Mirkin
2018-01-02 9:43 ` 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=e1b8dd62-4423-2b51-9634-e8938801b5d9@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=nouveau@lists.freedesktop.org \
--cc=tobias.johannes.klausmann@mni.thm.de \
/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