Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937085AbdLSNpK (ORCPT ); Tue, 19 Dec 2017 08:45:10 -0500 Received: from mail-wr0-f179.google.com ([209.85.128.179]:38217 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935056AbdLSNpJ (ORCPT ); Tue, 19 Dec 2017 08:45:09 -0500 X-Google-Smtp-Source: ACJfBotRdvfpiIwseThG8bgHAMFnLgogOt+GeqYPU57FZ4CsDPyQwXyOOMyudaaXvL8lQ4pKYu/wyA== Reply-To: christian.koenig@amd.com Subject: Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 To: =?UTF-8?Q?Michel_D=c3=a4nzer?= , Tobias Klausmann , Mike Galbraith Cc: nouveau , LKML , dri-devel , Ben Skeggs References: <1513620418.7113.51.camel@gmx.de> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Tue, 19 Dec 2017 14:45:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1644 Lines: 45 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 >> 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.