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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2FA9EC43334 for ; Fri, 24 Jun 2022 20:21:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5771C10F22D; Fri, 24 Jun 2022 20:21:58 +0000 (UTC) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by gabe.freedesktop.org (Postfix) with ESMTPS id CD98810F18F for ; Fri, 24 Jun 2022 20:21:56 +0000 (UTC) Received: by mail-ej1-x634.google.com with SMTP id fi2so6872640ejb.9 for ; Fri, 24 Jun 2022 13:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=aI/Wm30z63oEYhq+jLGxZI/tPMnn/tbFlzZ2xbhv+F4=; b=DSfCIl93ErkZQTmodLqWf6MxjRIpF1ZnQis6V2AmfYLHN/rGtlxKfpfQusYdU3/UoQ cGZ9t8NGw8N1UESLaZQtt9KE8BCcJRvCrZjHW4cY3x/vspkpF+H+OZ9YyYSAm/sR4To9 S80AKWsZyDrPVwQDWYceohfI1JDJJuzPD7o2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=aI/Wm30z63oEYhq+jLGxZI/tPMnn/tbFlzZ2xbhv+F4=; b=dhEtKw/qIrcajDnOjBp3znTSWi2wfEAu/ay4+gNmXIp6fgl5UCWpyLlTbV+XZNBFKD BvljtJaOluucuAyiq9x5Xz1LGB2PjLQcWNnbik4NaHt2Pb0/PLL0yP2AdJCcoAYB/UXd vjf+ylFxr1jnnjTF7wkj+031uUrjqLrDwffD8R+vfdsG8B0hvtYa66TUkKfPIgzv8Ha0 8Mc0fI2z2Azs29ZEZVEGDPnOtjQbMHVW9NwbH79PDPSB8xSGN5ChteZhnvTY/8BmQpsM tZK8+ik2zgLYEB28jgFIs0iCDzVAvLvVsPgKExn0IC7MbPZ6L1W1wrY0Er5/oMHtTpDo O81g== X-Gm-Message-State: AJIora925TtcMMuzd08nwgH8ENaFwPQ0MWDnJNAU8vI0CHJk/sGBTXr4 2KV9mhpC7ISwhJ5H0tFi8wdyxw== X-Google-Smtp-Source: AGRyM1vMLazEoSIRdqrX8zCM+3y9xklBh+nj+P3ouSsHUhI81GOe3I6uIj9foVrhcJrq+L6LjvY0lQ== X-Received: by 2002:a17:906:72d1:b0:722:e714:e9ff with SMTP id m17-20020a17090672d100b00722e714e9ffmr758067ejl.748.1656102115311; Fri, 24 Jun 2022 13:21:55 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id y22-20020a170906559600b00722e7919835sm1623844ejp.111.2022.06.24.13.21.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 13:21:54 -0700 (PDT) Date: Fri, 24 Jun 2022 22:21:52 +0200 From: Daniel Vetter To: Rob Clark Subject: Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker Message-ID: Mail-Followup-To: Rob Clark , Dmitry Osipenko , David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Daniel Almeida , Gert Wollny , Gustavo Padovan , Daniel Stone , Tomeu Vizoso , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Herring , Steven Price , Alyssa Rosenzweig , Emil Velikov , Robin Murphy , Qiang Yu , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , "Pan, Xinhui" , Thierry Reding , Tomasz Figa , Marek Szyprowski , Mauro Carvalho Chehab , Alex Deucher , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Dmitry Osipenko , linux-tegra@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, kernel@collabora.com References: <20220526235040.678984-1-dmitry.osipenko@collabora.com> <20220526235040.678984-18-dmitry.osipenko@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.0-8-amd64 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Joonas Lahtinen , dri-devel@lists.freedesktop.org, Gurchetan Singh , Thierry Reding , Gerd Hoffmann , Dmitry Osipenko , kernel@collabora.com, Sumit Semwal , Marek Szyprowski , Rob Herring , Daniel Stone , Steven Price , Gustavo Padovan , Alyssa Rosenzweig , Dmitry Osipenko , virtualization@lists.linux-foundation.org, Chia-I Wu , linux-media@vger.kernel.org, Daniel Vetter , intel-gfx@lists.freedesktop.org, Maarten Lankhorst , Maxime Ripard , linaro-mm-sig@lists.linaro.org, Jani Nikula , Rodrigo Vivi , linux-tegra@vger.kernel.org, Mauro Carvalho Chehab , Tvrtko Ursulin , Daniel Almeida , amd-gfx@lists.freedesktop.org, Tomeu Vizoso , Gert Wollny , "Pan, Xinhui" , Emil Velikov , linux-kernel@vger.kernel.org, Tomasz Figa , Qiang Yu , Thomas Zimmermann , Alex Deucher , Robin Murphy , Christian =?iso-8859-1?Q?K=F6nig?= Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote: > On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko > wrote: > > + mutex_unlock(&gem_shrinker->lock); > > As I mentioned on other thread, count_objects, being approximate but > lockless and fast is the important thing. Otherwise when you start > hitting the shrinker on many threads, you end up serializing them all, > even if you have no pages to return to the system at that point. Yeah agreed, seems like I was wrong here :-) Atomic counter or something would also be in link the the lru_list stuff. It would be to record this in the kerneldoc for the shrinker structure though, to make sure this is all understood. > > + /* prevent racing with the dma-buf importing/exporting */ > > + if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) { > > + *lock_contention |= true; > > + goto resv_unlock; > > + } > > I'm not sure this is a good idea to serialize on object_name_lock. > Purgeable buffers should never be shared (imported or exported). So > at best you are avoiding evicting and immediately swapping back in, in > a rare case, at the cost of serializing multiple threads trying to > reclaim pages in parallel. Yeah this sounds really bad. Plus this is a per-device lock, and doing those with trylock means the shrinker will fail to find shrinkable memory way too often. We need to engineer this out somehow. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch