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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33CC1CCA47E for ; Fri, 24 Jun 2022 20:21:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231199AbiFXUV6 (ORCPT ); Fri, 24 Jun 2022 16:21:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbiFXUV5 (ORCPT ); Fri, 24 Jun 2022 16:21:57 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDFFE82895 for ; Fri, 24 Jun 2022 13:21:56 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id cw10so6930854ejb.3 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=tFtrQEegPWL8eE1OlhFTp0vJum2+xmlrRlvjCjXtL9ELQa07nsUJUd09BohjtnBa9e 87X44VlhSRfsBbEWCLtTC8LXH4a8HjrCo+pTO7p/5GuqCLpB1T2yAMKk3kk+5rrExn2S lpNetH9dq57+173aKd7rM9fYTy9ogNTTJPY/N+ArEqHd7y0hvmBDdXFJuXyL8V81tSfO Tv5TOqiXdFSJD9OC+LssqmbTMJmCOLZ59+46mmmotMswOGfhCGNjEY+I/Qx0F5zqp4lQ pYCkF2s9hkMZTP/UUO9UAs6abNad6KR+eWx9Qze+khmbY8GvA/d0YteTC44+k3RwBwWL JFLQ== X-Gm-Message-State: AJIora9TQgCRvGwiin3CL5QsCwx/2oNieqXgzP48NUtbjuR1kswhxr2Y DOKEl71EyTwNWbmOu0l72niPWA== 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 Cc: Dmitry Osipenko , David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Daniel Vetter , 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 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 Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org 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