From patchwork Fri Mar 24 09:24:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Michel_D=C3=A4nzer?= X-Patchwork-Id: 9642437 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9F41560327 for ; Fri, 24 Mar 2017 09:25:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A542926E97 for ; Fri, 24 Mar 2017 09:25:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 98B2328339; Fri, 24 Mar 2017 09:25:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id A6B3C26E97 for ; Fri, 24 Mar 2017 09:25:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 95E556E32D; Fri, 24 Mar 2017 09:25:07 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from netline-mail3.netline.ch (mail.netline.ch [148.251.143.178]) by gabe.freedesktop.org (Postfix) with ESMTP id AE6B36E32D; Fri, 24 Mar 2017 09:25:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id C51D42E2004; Fri, 24 Mar 2017 10:25:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GOL6yJQSLuJe; Fri, 24 Mar 2017 10:25:04 +0100 (CET) Received: from thor (42-144-27-164.rev.home.ne.jp [42.144.27.164]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id 56EBA2E2002; Fri, 24 Mar 2017 10:25:04 +0100 (CET) Received: from localhost ([::1]) by thor with esmtp (Exim 4.89) (envelope-from ) id 1crLSt-0006yf-T8; Fri, 24 Mar 2017 18:24:59 +0900 Subject: Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first" To: Julien Isorce References: <1490206797-15653-1-git-send-email-zmichaels@oblong.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <8020e778-c9c8-e67b-428a-436f2f1c0d7b@daenzer.net> Date: Fri, 24 Mar 2017 18:24:59 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Cc: Zachary Michaels , dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 23/03/17 06:26 PM, Julien Isorce wrote: > Hi Michel, > > When it happens, the main thread of our gl based app is stuck on a > ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but > same thing happens if true. Other threads are only si_shader:0,1,2,3 and > are doing nothing, just waiting for jobs. I can also do sudo gdb -p > $(pidof Xorg) to block the X11 server, to make sure there is no ping > pong between 2 processes. All other processes are not loading > dri/radeonsi_dri.so . And adding a few traces shows that the above ioctl > call is looping for ever on > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/ttm/ttm_bo.c#L819 > and > comes from > mesa https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/radeon/drm/radeon_drm_cs.c#n454 > . > > After adding even more traces I can see that the bo, which is being > indefinitely evicted, has the flag RADEON_GEM_NO_CPU_ACCESS. > And it gets 3 potential placements after calling "radeon_evict_flags". > 1: VRAM cpu inaccessible, fpfn is 65536 > 2: VRAM cpu accessible, fpfn is 0 > 3: GTT, fpfn is 0 > > And it looks like it continuously succeeds to move on the second > placement. So I might be wrong but it looks it is not even a ping pong > between VRAM accessible / not accessible, it just keeps being blited in > the CPU accessible part of the VRAM. Thanks for the detailed description! AFAICT this can only happen due to a silly mistake I made in this code. Does this fix it? diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5c7cf644ba1d..37d68cd1f272 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -213,8 +213,8 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo, rbo->placement.num_busy_placement = 0; for (i = 0; i < rbo->placement.num_placement; i++) { if (rbo->placements[i].flags & TTM_PL_FLAG_VRAM) { - if (rbo->placements[0].fpfn < fpfn) - rbo->placements[0].fpfn = fpfn; + if (rbo->placements[i].fpfn < fpfn) + rbo->placements[i].fpfn = fpfn; } else { rbo->placement.busy_placement = &rbo->placements[i];