From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C515C433ED for ; Tue, 18 May 2021 16:09:11 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E34E9611CE for ; Tue, 18 May 2021 16:09:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E34E9611CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D01F6EC1C; Tue, 18 May 2021 16:09:10 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 50ACE6EC2C; Tue, 18 May 2021 16:09:09 +0000 (UTC) IronPort-SDR: ZgjL7T0OfixtTL1IPGHKl4PGOrfIErJcrUlibSLCu+rdt2dYkrwV7bkilIth1HjZ3L/EqiFqku w7vamOejuvEA== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="200804788" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="200804788" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 09:07:29 -0700 IronPort-SDR: iDotVLPyfjU7FBk7NwaJk3sZv4BntYDY9mnTI5dVeVC14EdCSg+u9NYwbTBJBBfHkz+Pw+Wpv7 3/SlzzoQRRCA== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439100599" Received: from cmutgix-mobl.gar.corp.intel.com (HELO [10.249.254.195]) ([10.249.254.195]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 09:07:27 -0700 Subject: Re: [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping To: =?UTF-8?Q?Christian_K=c3=b6nig?= , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org References: <20210518082701.997251-1-thomas.hellstrom@linux.intel.com> <20210518082701.997251-10-thomas.hellstrom@linux.intel.com> <60276369-dbfd-e0dc-548b-a9419ff4c7eb@amd.com> <471d8fd5-379f-e95a-4973-c50fadace7cb@linux.intel.com> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= Message-ID: <334dc2d2-2053-9e42-62be-58784e4256aa@linux.intel.com> Date: Tue, 18 May 2021 18:07:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 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" On 5/18/21 5:42 PM, Christian König wrote: > Am 18.05.21 um 17:38 schrieb Thomas Hellström: >> >> On 5/18/21 5:28 PM, Christian König wrote: >>> Am 18.05.21 um 17:20 schrieb Thomas Hellström: >>>> >>>> On 5/18/21 5:18 PM, Christian König wrote: >>>>> >>>>> >>>>> Am 18.05.21 um 17:15 schrieb Thomas Hellström: >>>>>> >>>>>> On 5/18/21 10:26 AM, Thomas Hellström wrote: >>>>>>> We are calling the eviction_valuable driver callback at eviction >>>>>>> time to >>>>>>> determine whether we actually can evict a buffer object. >>>>>>> The upcoming i915 TTM backend needs the same functionality for >>>>>>> swapout, >>>>>>> and that might actually be beneficial to other drivers as well. >>>>>>> >>>>>>> Add an eviction_valuable call also in the swapout path. Try to >>>>>>> keep the >>>>>>> current behaviour for all drivers by returning true if the >>>>>>> buffer object >>>>>>> is already in the TTM_PL_SYSTEM placement. We change behaviour >>>>>>> for the >>>>>>> case where a buffer object is in a TT backed placement when >>>>>>> swapped out, >>>>>>> in which case the drivers normal eviction_valuable path is run. >>>>>>> >>>>>>> Finally export ttm_tt_unpopulate() and don't swap out bos >>>>>>> that are not populated. This allows a driver to purge a bo at >>>>>>> swapout time if its content is no longer valuable rather than to >>>>>>> have TTM swap the contents out. >>>>>>> >>>>>>> Cc: Christian König >>>>>>> Signed-off-by: Thomas Hellström >>>>>> >>>>>> Christian, >>>>>> >>>>>> Here we have a ttm_tt_unpopulate() export as well at the end. I >>>>>> figure you will push back on that one. What we really need is a >>>>>> functionality to just drop the bo contents and end up in system >>>>>> memory unpopulated. Should I perhaps add a utility function to do >>>>>> that instead? like ttm_bo_purge()? >>>>> >>>>> We already have that. Just call ttm_bo_validate() without any >>>>> place to put the buffer. >>>>> >>>>> See how ttm_bo_pipeline_gutting() is used. >>>>> >>>>> Christian. >>>> >>>> OK, so is that reentrant from the move() or swap_notify() callback. >>> >>> That sounds like a design bug to me since you should never need to >>> do this. >>> >>> When you want to destroy the backing store of a buffer during >>> eviction you should just do this by returning an empty placement >>> from the evict_flags callback. >> >> So this is for the functionality where the user has indicated that >> the contents is no longer of value, but the buffer itself >> is cached until evicted or swapped out for performance reasons. So >> the above would work for eviction, but what about swapout. Could we >> add some similar functionality there? > > Amdgpu has the same functionality and you don't need to handle swap at > all. > > Just return from the evict_flags that you want to drop the backing > store as soon as the BO leaves the GTT domain. Hmm, the pipeline_gutting function seems ok, but overly complex if the bo is already idle, Am I allowed to optimize it slightly for the latter case? /Thomas > > Christian. > >> >> /Thomas >> >>> >>> Regards, >>> Christian. >>> >>>> >>>> /Thomas >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>> >>> >