Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1186069pxb; Fri, 18 Feb 2022 02:27:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJy3uM/TAwofglnwybLqog5iyNoAGRBa0o1BYGXE9uA/b8FKJhI5AS3VyI/UmvG2RFV+Kh8b X-Received: by 2002:a05:6a00:8c5:b0:4c7:f9a5:ebc6 with SMTP id s5-20020a056a0008c500b004c7f9a5ebc6mr7357828pfu.34.1645180032976; Fri, 18 Feb 2022 02:27:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645180032; cv=none; d=google.com; s=arc-20160816; b=r+DbvOdCL9C3cRn7kyQH5DZl3Np0T9l9t5ZyZnpUnlyvXMCwtblb6/sOqEyzgD0jzO ZARRnJcjDqiFViZuJQlD+05bHhvH15TVDHcuOXXY5c+gEhuvhvfCSLCYlDm/D28s31lg s+ur8xLSgQAg+7SoFiDFJ0prAfhw5sHGWkh5AiAbZtY3AR5HFF3x8NSGDi4Lhi5ploFC sRXDZP+nFv2Q79pNBtMxz2VOohaf1olNFoQfvZTGDgfwncbVzxC3r9orGkV15vxrLpzE n0Q03/OJ6D06HfInXKbmf/5fMK4XNJ6+lAbgxdx2umDBcWBk+TVXtPgnYZcjEFTrfP2P NJLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=2NUwjlP/vOuIBV1np9NiJ3HRb/wklk2YI9wob6stFns=; b=YP8MFJep69OGJbi91dLVjB70fvFGhq9+pBIH8Hzg+4t1ePngP8hCUtlL10VkT6NLpp W3jRVkEkYJnX4grR/WnrUQC1Ju9u+kyn3/a2Gspo8BC2rwMu02cTHQSq+jlzcB3SWMEB efcGnVg2mcynS4yB1eDzgEpBqBd5k6+KF8qwOY4cz6DOjY4h/d6hj/UqkceTyXkonvLK vLKFRV/6phQuFf483PBLxXo197mLkggf6x2lnwGthnrWZmT26hOaIzqMBpurNgJErtEo 3Wg0RYZVXRMKGNw/CsIgcy+eYICRbuCt3ZiLoi6HR+mY6JnfrJEyx3VM2hYVY+GIf6cD Ewqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="homC/eRQ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e187si10708318pgc.370.2022.02.18.02.26.58; Fri, 18 Feb 2022 02:27:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="homC/eRQ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234060AbiBRKQz (ORCPT + 99 others); Fri, 18 Feb 2022 05:16:55 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:52146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234004AbiBRKQj (ORCPT ); Fri, 18 Feb 2022 05:16:39 -0500 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 269D12AF3D3; Fri, 18 Feb 2022 02:16:23 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id a12-20020a05683012cc00b005acf7c91097so1623564otq.10; Fri, 18 Feb 2022 02:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2NUwjlP/vOuIBV1np9NiJ3HRb/wklk2YI9wob6stFns=; b=homC/eRQJMsRMmXyrAPjGInfnbZQD9EX04WzWGdutnjhIOt9SnqRsvqzHNgL5SOqaU g9YQOytY9SRRGbgGijzgUot4R0+VAAEhYu151SIewSwj6KwD9c8IjZTOBM0tTr2Gid3P 5ywlkMam0o7fAty02Se9WbQI1EM+ZVX4pe2h2aUUkrIu3YA/BZ+vb7o5AHiOxQSXE55I 260Z4QLQyx7NpLODLhTJgeEShtTych73O10QrU1wqTAHksMfF/5lTZGCcUnGFCIqmdMN UVmK2j6Jc+0Nw8q44oeeeTs7YU0KXzw2CE27SMh2Dr9TP2xcnO/HWbF4yVJwuONt8BU8 B0KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2NUwjlP/vOuIBV1np9NiJ3HRb/wklk2YI9wob6stFns=; b=2/0mRkVyZyLsGDJnFYJ+EFjs7Yne11iFE/ciw2tLkatNiCh4H8Z80jkZ/BoHmcFx7v +S5mb1VSUSA59kVmJeQtS1JQs9XNzqp2QtgdKQLCz9pCuHALwJCcLLtzFfVzdJztsUIe ZN1Z2dqFTBrkfhe0cGiWon4mejLRWP0PAO4OLja8cj6CS+DS/GRSvgvFX5CCMFda3tDL 74MoQ+qUAjDY5LDwHg1gCWB0k3Q42lFcs6uswarvx6dK4IODWA3zBFtBqc15J3PQpbgM m/VIy20yAGBVwMz6GYnuZ25+4gBSDvBH7Urzz+qEM+11zZ6yvDp9f2a6KpHwJx/Ee7vG u4Cg== X-Gm-Message-State: AOAM531a+bus39k9zH3B96egEQXrrtKNrROF5YqWOs4PS3YBrbeaTOM2 3J7xj7q6UqMWQPNPTJKZKJuvuM8Wwsa9ODuvxJw8rxDQyZfht3ME87Q= X-Received: by 2002:a9d:715c:0:b0:5ad:3858:4d54 with SMTP id y28-20020a9d715c000000b005ad38584d54mr251368otj.214.1645179382348; Fri, 18 Feb 2022 02:16:22 -0800 (PST) MIME-Version: 1.0 References: <20220217090440.4468-1-qiang.yu@amd.com> <5d3fdd2c-e74a-49f4-2b28-32c06483236f@amd.com> <6711073b-8771-5750-33f7-b72333b411c6@amd.com> In-Reply-To: From: Qiang Yu Date: Fri, 18 Feb 2022 18:16:08 +0800 Message-ID: Subject: Re: [PATCH] drm/amdgpu: check vm bo eviction valuable at last To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , David Airlie , "Pan, Xinhui" , Linux Kernel Mailing List , dri-devel , linaro-mm-sig@lists.linaro.org, Qiang Yu , amd-gfx@lists.freedesktop.org, Daniel Vetter , Alex Deucher , Sumit Semwal , linux-media@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 18, 2022 at 5:27 PM Christian K=C3=B6nig wrote: > > Am 18.02.22 um 09:58 schrieb Qiang Yu: > > On Fri, Feb 18, 2022 at 3:46 PM Christian K=C3=B6nig > > wrote: > >> Am 18.02.22 um 04:08 schrieb Qiang Yu: > >>> On Thu, Feb 17, 2022 at 8:22 PM Christian K=C3=B6nig > >>> wrote: > >>>> Am 17.02.22 um 11:58 schrieb Qiang Yu: > >>>>> On Thu, Feb 17, 2022 at 6:39 PM Christian K=C3=B6nig > >>>>> wrote: > >>>>>> Am 17.02.22 um 11:13 schrieb Qiang Yu: > >>>>>>> On Thu, Feb 17, 2022 at 5:46 PM Christian K=C3=B6nig > >>>>>>> wrote: > >>>>>>>> Am 17.02.22 um 10:40 schrieb Qiang Yu: > >>>>>>>>> On Thu, Feb 17, 2022 at 5:15 PM Christian K=C3=B6nig > >>>>>>>>> wrote: > >>>>>>>>>> Am 17.02.22 um 10:04 schrieb Qiang Yu: > >>>>>>>>>>> Workstation application ANSA/META get this error dmesg: > >>>>>>>>>>> [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO= _VA (-16) > >>>>>>>>>>> > >>>>>>>>>>> This is caused by: > >>>>>>>>>>> 1. create a 256MB buffer in invisible VRAM > >>>>>>>>>>> 2. CPU map the buffer and access it causes vm_fault and try t= o move > >>>>>>>>>>> it to visible VRAM > >>>>>>>>>>> 3. force visible VRAM space and traverse all VRAM bos to chec= k if > >>>>>>>>>>> evicting this bo is valuable > >>>>>>>>>>> 4. when checking a VM bo (in invisible VRAM), amdgpu_vm_evict= able() > >>>>>>>>>>> will set amdgpu_vm->evicting, but latter due to not = in visible > >>>>>>>>>>> VRAM, won't really evict it so not add it to amdgpu_= vm->evicted > >>>>>>>>>>> 5. before next CS to clear the amdgpu_vm->evicting, user VM o= ps > >>>>>>>>>>> ioctl will pass amdgpu_vm_ready() (check amdgpu_vm->= evicted) > >>>>>>>>>>> but fail in amdgpu_vm_bo_update_mapping() (check > >>>>>>>>>>> amdgpu_vm->evicting) and get this error log > >>>>>>>>>>> > >>>>>>>>>>> This error won't affect functionality as next CS will finish = the > >>>>>>>>>>> waiting VM ops. But we'd better make the amdgpu_vm->evicting > >>>>>>>>>>> correctly reflact the vm status and clear the error log. > >>>>>>>>>> Well NAK, that is intentional behavior. > >>>>>>>>>> > >>>>>>>>>> The VM page tables where considered for eviction, so setting t= he flag is > >>>>>>>>>> correct even when the page tables later on are not actually ev= icted. > >>>>>>>>>> > >>>>>>>>> But this will unnecessarily stop latter user VM ops in ioctl be= fore CS > >>>>>>>>> even when the VM bos are not evicted. > >>>>>>>>> Won't this have any negative effect when could do better? > >>>>>>>> No, this will have a positive effect. See the VM was already con= sidered > >>>>>>>> for eviction because it is idle. > >>>>>>>> > >>>>>>>> Updating it immediately doesn't necessarily make sense, we shoul= d wait > >>>>>>>> with that until its next usage. > >>>>>>>> > >>>>>>>> Additional to that this patch doesn't really fix the problem, it= just > >>>>>>>> mitigates it. > >>>>>>>> > >>>>>>>> Eviction can fail later on for a couple of reasons and we absolu= tely > >>>>>>>> need to check the flag instead of the list in amdgpu_vm_ready(). > >>>>>>> The flag only for both flag and list? Looks like should be both a= s > >>>>>>> the list indicate some vm page table need to be updated and could > >>>>>>> delay the user update with the same logic as you described above. > >>>>>> I think checking the flag should be enough. The issue is that the = list > >>>>>> was there initially, but to avoid race conditions we added the fla= g with > >>>>>> separate lock protection later on. > >>>>>> > >>>>> But list and flag does not align always, there are cases like > >>>>> list-empty/flag-set (this problem) and list-non-empty/flag-unset (n= on-vm bo > >>>>> eviction). If only check flag list-non-empty/flag-unset change beha= vior. > >>>> Yeah, but I think that the flag unset list-non-empty case would be > >>>> correctly handled if we only test the flag. > >>>> > >>>> In other words we can update the page tables as long as they are not > >>>> partially or fully evicted and that's not the case when non-vm BOs a= re > >>>> evicted. > >>>> > >>> This sounds like two standard for the same thing, because this proble= m > >>> does not evict page tables too. But I see your point is: > >>> There's a difference that this problem's case can make sure vm is idl= e, > >>> and we prefer to delay vm updates when vm is idle. > >>> > >>> If so, why not just stop user vm update by checking vm busy in > >>> amdgpu_gem_va_ioctl() to skip amdgpu_gem_va_update_vm()? > >> That's exactly what amdgpu_gem_va_update_vm() is doing by calling > >> amdgpu_vm_ready(). The problem is that amdgpu_vm_ready() looks at the > >> wrong thing. > >> > > If amdgpu_vm_ready() use evicting flag, it's still not equivalent to ch= eck > > vm idle: true -> vm idle, false -> vm may be idle or busy. > > Yeah, but why should that be relevant? > > The amdgpu_vm_ready() return if we can do page table updates or not. If > the VM is idle or not is only relevant for eviction. > > In other words any CS or page table update makes the VM busy, but that > only affects if the VM can be evicted or not. > My point is: we can't use amdgpu_vm_ready() to replace vm_is_busy(), so currently we update vm even when vm is busy. So why not use: if (!amdgpu_vm_ready() || vm_is_busy()) return; in amdgpu_gem_va_update_vm(), as you mentioned we prefer to not update vm when it's idle. > >>> Then we can keep the evicting flag accurate (after solving your > >>> concern for this patch that eviction may fail latter by further delay > >>> the flag update after eviction success). > >> That won't work. See we need to mark the VM as evicted before we > >> actually evict them because otherwise somebody could use the VM in > >> parallel and add another fence to it. > >> > > I see, make this too accurate should cost too much like holding the > > eviction_lock when eviction. But just delay it in > > amdgpu_ttm_bo_eviction_valuable() > > could avoid most false positive case. > > Partially correct. Another fundamental problem is that we can't hold the > eviction lock because that would result in lock inversion and potential > deadlock. > > We could set the flag later on, but as I said before that when we set > the evicted flag when the VM is already idle is a desired effect. > As above, this confuse me as we can explicitly check vm idle when user update vm, why bother to embed it in evicting flag implicitly? Check vm idle need to hold resv lock. Read your patch for adding evicting flag is to update vm without resv lock. But user vm ops in amdgpu_gem_va_update_vm() do hold the resv lock, so the difference happens when calling amdgpu_vm_bo_update_mapping() from svm_range_(un)map_to_gpu(). So embed vm idle in evicting flag is for svm_range_(un)map_to_gpu() also do nothing when vm idle? Regards, Qiang > Regards, > Christian. > > > > > Regards, > > Qiang > > > >> Regards, > >> Christian. > >> > >>> Regards, > >>> Qiang > >>> > >>> > >>>> Regards, > >>>> Christian. > >>>> > >>>>> Regards, > >>>>> Qiang > >>>>> > >>>>>> Regards, > >>>>>> Christian. > >>>>>> > >>>>>>> Regards, > >>>>>>> Qiang > >>>>>>> > >>>>>>>> Regards, > >>>>>>>> Christian. > >>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Qiang > >>>>>>>>> > >>>>>>>>>> What we should rather do is to fix amdgpu_vm_ready() to take a= look at > >>>>>>>>>> the flag instead of the linked list. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Christian. > >>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Qiang Yu > >>>>>>>>>>> --- > >>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 85 +++++++++= +++++----------- > >>>>>>>>>>> 1 file changed, 47 insertions(+), 38 deletions(-) > >>>>>>>>>>> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/driver= s/gpu/drm/amd/amdgpu/amdgpu_ttm.c > >>>>>>>>>>> index 5a32ee66d8c8..88a27911054f 100644 > >>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > >>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > >>>>>>>>>>> @@ -1306,45 +1306,11 @@ uint64_t amdgpu_ttm_tt_pte_flags(stru= ct amdgpu_device *adev, struct ttm_tt *ttm, > >>>>>>>>>>> return flags; > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> -/* > >>>>>>>>>>> - * amdgpu_ttm_bo_eviction_valuable - Check to see if we can = evict a buffer > >>>>>>>>>>> - * object. > >>>>>>>>>>> - * > >>>>>>>>>>> - * Return true if eviction is sensible. Called by ttm_mem_ev= ict_first() on > >>>>>>>>>>> - * behalf of ttm_bo_mem_force_space() which tries to evict b= uffer objects until > >>>>>>>>>>> - * it can find space for a new object and by ttm_bo_force_li= st_clean() which is > >>>>>>>>>>> - * used to clean out a memory space. > >>>>>>>>>>> - */ > >>>>>>>>>>> -static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffe= r_object *bo, > >>>>>>>>>>> - const struct ttm_pl= ace *place) > >>>>>>>>>>> +static bool amdgpu_ttm_mem_eviction_valuable(struct ttm_buff= er_object *bo, > >>>>>>>>>>> + const struct ttm_p= lace *place) > >>>>>>>>>>> { > >>>>>>>>>>> unsigned long num_pages =3D bo->resource->num_page= s; > >>>>>>>>>>> struct amdgpu_res_cursor cursor; > >>>>>>>>>>> - struct dma_resv_list *flist; > >>>>>>>>>>> - struct dma_fence *f; > >>>>>>>>>>> - int i; > >>>>>>>>>>> - > >>>>>>>>>>> - /* Swapout? */ > >>>>>>>>>>> - if (bo->resource->mem_type =3D=3D TTM_PL_SYSTEM) > >>>>>>>>>>> - return true; > >>>>>>>>>>> - > >>>>>>>>>>> - if (bo->type =3D=3D ttm_bo_type_kernel && > >>>>>>>>>>> - !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo))) > >>>>>>>>>>> - return false; > >>>>>>>>>>> - > >>>>>>>>>>> - /* If bo is a KFD BO, check if the bo belongs to the cu= rrent process. > >>>>>>>>>>> - * If true, then return false as any KFD process needs = all its BOs to > >>>>>>>>>>> - * be resident to run successfully > >>>>>>>>>>> - */ > >>>>>>>>>>> - flist =3D dma_resv_shared_list(bo->base.resv); > >>>>>>>>>>> - if (flist) { > >>>>>>>>>>> - for (i =3D 0; i < flist->shared_count; ++i) { > >>>>>>>>>>> - f =3D rcu_dereference_protected(flist->= shared[i], > >>>>>>>>>>> - dma_resv_held(bo->base.resv)); > >>>>>>>>>>> - if (amdkfd_fence_check_mm(f, current->m= m)) > >>>>>>>>>>> - return false; > >>>>>>>>>>> - } > >>>>>>>>>>> - } > >>>>>>>>>>> > >>>>>>>>>>> switch (bo->resource->mem_type) { > >>>>>>>>>>> case AMDGPU_PL_PREEMPT: > >>>>>>>>>>> @@ -1377,10 +1343,53 @@ static bool amdgpu_ttm_bo_eviction_va= luable(struct ttm_buffer_object *bo, > >>>>>>>>>>> return false; > >>>>>>>>>>> > >>>>>>>>>>> default: > >>>>>>>>>>> - break; > >>>>>>>>>>> + return ttm_bo_eviction_valuable(bo, place); > >>>>>>>>>>> } > >>>>>>>>>>> +} > >>>>>>>>>>> > >>>>>>>>>>> - return ttm_bo_eviction_valuable(bo, place); > >>>>>>>>>>> +/* > >>>>>>>>>>> + * amdgpu_ttm_bo_eviction_valuable - Check to see if we can = evict a buffer > >>>>>>>>>>> + * object. > >>>>>>>>>>> + * > >>>>>>>>>>> + * Return true if eviction is sensible. Called by ttm_mem_ev= ict_first() on > >>>>>>>>>>> + * behalf of ttm_bo_mem_force_space() which tries to evict b= uffer objects until > >>>>>>>>>>> + * it can find space for a new object and by ttm_bo_force_li= st_clean() which is > >>>>>>>>>>> + * used to clean out a memory space. > >>>>>>>>>>> + */ > >>>>>>>>>>> +static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffe= r_object *bo, > >>>>>>>>>>> + const struct ttm_pl= ace *place) > >>>>>>>>>>> +{ > >>>>>>>>>>> + struct dma_resv_list *flist; > >>>>>>>>>>> + struct dma_fence *f; > >>>>>>>>>>> + int i; > >>>>>>>>>>> + > >>>>>>>>>>> + /* Swapout? */ > >>>>>>>>>>> + if (bo->resource->mem_type =3D=3D TTM_PL_SYSTEM) > >>>>>>>>>>> + return true; > >>>>>>>>>>> + > >>>>>>>>>>> + /* If bo is a KFD BO, check if the bo belongs to the cu= rrent process. > >>>>>>>>>>> + * If true, then return false as any KFD process needs = all its BOs to > >>>>>>>>>>> + * be resident to run successfully > >>>>>>>>>>> + */ > >>>>>>>>>>> + flist =3D dma_resv_shared_list(bo->base.resv); > >>>>>>>>>>> + if (flist) { > >>>>>>>>>>> + for (i =3D 0; i < flist->shared_count; ++i) { > >>>>>>>>>>> + f =3D rcu_dereference_protected(flist->= shared[i], > >>>>>>>>>>> + dma_resv_held(bo->base.resv)); > >>>>>>>>>>> + if (amdkfd_fence_check_mm(f, current->m= m)) > >>>>>>>>>>> + return false; > >>>>>>>>>>> + } > >>>>>>>>>>> + } > >>>>>>>>>>> + > >>>>>>>>>>> + /* Check by different mem type. */ > >>>>>>>>>>> + if (!amdgpu_ttm_mem_eviction_valuable(bo, place)) > >>>>>>>>>>> + return false; > >>>>>>>>>>> + > >>>>>>>>>>> + /* VM bo should be checked at last because it will mark= VM evicting. */ > >>>>>>>>>>> + if (bo->type =3D=3D ttm_bo_type_kernel) > >>>>>>>>>>> + return amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)= ); > >>>>>>>>>>> + > >>>>>>>>>>> + return true; > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> static void amdgpu_ttm_vram_mm_access(struct amdgpu_de= vice *adev, loff_t pos, >