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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 E6A65C35666 for ; Sun, 23 Feb 2020 15:45:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AFAEB206E0 for ; Sun, 23 Feb 2020 15:45:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hYw76MzT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726748AbgBWPpS (ORCPT ); Sun, 23 Feb 2020 10:45:18 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:39201 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726302AbgBWPpS (ORCPT ); Sun, 23 Feb 2020 10:45:18 -0500 Received: by mail-wm1-f66.google.com with SMTP id c84so6815532wme.4 for ; Sun, 23 Feb 2020 07:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=inzn9KgooBAx5M8NGIgtozNP6e9nFtoEVn58fHfHS9U=; b=hYw76MzTFFctGmd2sCZFPBrCelb2cowVUlYA/AM1Mvij3bAAMGhlNYI0rXUyDABN1Z 3xnZU9YMt1g+8dxTLcHslrSYtN5qhEKRhjfGJjKacSGiPP2zDpUV6GpuaBsjENJ5rp55 0avPNo7K+rwCSa4uwE970DBGcopjfo26u+SjVLwGhH7MMCFk9TzZNgGma7wEJ07pI0L7 0Kln0X7vwiTJduenaOPAj0ddeX47KooxkTj5sNpoZLc5xD5l+sK34dEtrWWnL+II+aaT bu5X7itzmxjo3NBXoW1/JcihM6tqGVze2sSaY8eNYVgJ7JP2g1QLDt6FRNZqVMGHqZ48 04ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=inzn9KgooBAx5M8NGIgtozNP6e9nFtoEVn58fHfHS9U=; b=X3nbsLrP+gXOV2NI6pEKG4W5Wu+3wAvaSuyowUzoGWG2imBFHxXuBkeOwEUC6oVhNo /R+EvcLx6AHfQwsI61lo/IjXu/yhE1BhIJCzXsEASzN77VwpiuRcVX83+QgnfAyWw5Ss qvB+mMQrEKd8Tc193rsLEoOqUTRZ9pcRFPP80ZVJhVcgbUx2lFhAeb7kvH5LhqWDomDP pOpF22h7NWimRltG/tOVznF9tHI3KiyriQDZLp+z2S4pGqdddo6sEswMxpDtB+0pr1bn cqZGK31LvafH41ZLTWtxNiekhS2Gjm5z6ccCwVR9PsYYr+AoWAIZafxUKrbjQnuQoZMR 37Xw== X-Gm-Message-State: APjAAAWsL1Dwtc6h+YQ0rnee+w8vhvLvCzk2dDIiGf7mKdLp399ErGQ4 Ullft2tuOI8YZR1LN20wY18HX49j X-Google-Smtp-Source: APXvYqxhJh1O9a4M4aCqcycel5moNklWx8r/xJq6nuMHEP0zx83oOzF3CBVTxvvIT9/L5THTkiHlGw== X-Received: by 2002:a7b:c14e:: with SMTP id z14mr16451275wmi.58.1582472716864; Sun, 23 Feb 2020 07:45:16 -0800 (PST) Received: from ?IPv6:2a02:908:1252:fb60:be8a:bd56:1f94:86e7? ([2a02:908:1252:fb60:be8a:bd56:1f94:86e7]) by smtp.gmail.com with ESMTPSA id w7sm13097479wmi.9.2020.02.23.07.45.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2020 07:45:16 -0800 (PST) Reply-To: christian.koenig@amd.com Subject: Re: [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2 To: Daniel Vetter , =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28VMware=29?= Cc: intel-gfx , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:DMA BUFFER SHARING FRAMEWORK" References: <20200217154509.2265-6-christian.koenig@amd.com> <20200217175518.GL2363188@phenom.ffwll.local> <79a0d79f-91bd-2481-740c-20e6c819c7c9@shipmail.org> <20200220180459.GS2363188@phenom.ffwll.local> <20200220200831.GA2363188@phenom.ffwll.local> <501bf409-e4fe-a318-17b4-d5d050b09529@shipmail.org> <20200221171217.GD2363188@phenom.ffwll.local> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Sun, 23 Feb 2020 16:45:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200221171217.GD2363188@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Am 21.02.20 um 18:12 schrieb Daniel Vetter: > [SNIP] > Yeah the Great Plan (tm) is to fully rely on ww_mutex slowly degenerating > into essentially a global lock. But only when there's actual contention > and thrashing. Yes exactly. A really big problem in TTM is currently that we drop the lock after evicting BOs because they tend to move in again directly after that. From practice I can also confirm that there is exactly zero benefit from dropping locks early and reacquire them for example for the VM page tables. That's just makes it more likely that somebody needs to roll back and this is what we need to avoid in the first place. Contention on BO locks during command submission is perfectly fine as long as this is as lightweight as possible while we don't have trashing. When we have trashing multi submission performance is best archived to just favor a single process to finish its business and block everybody else. Because of this I would actually vote for forbidding to release individual ww_mutex() locks in a context. Regards, Christian. > -Daniel