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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS 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 9A51DC433ED for ; Thu, 15 Apr 2021 20:33:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 201C261139 for ; Thu, 15 Apr 2021 20:33:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 201C261139 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4BFBE6B0036; Thu, 15 Apr 2021 16:33:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46F716B006C; Thu, 15 Apr 2021 16:33:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 310196B0070; Thu, 15 Apr 2021 16:33:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 127716B0036 for ; Thu, 15 Apr 2021 16:33:15 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C8A483640 for ; Thu, 15 Apr 2021 20:33:14 +0000 (UTC) X-FDA: 78035751108.39.E45208A Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf10.hostedemail.com (Postfix) with ESMTP id 76B3140002D2 for ; Thu, 15 Apr 2021 20:33:08 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 7F2B561131; Thu, 15 Apr 2021 20:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1618518791; bh=W2nMmH/TIbeIB5kU2kUp8LI+os2a3rcGm1HyUvE3oCs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bMN/FgOL0iZZcydKxfGEO6IUq8f9VCFjKW5nDFVmpFmRHDHbX+bZcY7CmDZkf3cZA 212qkV1WoyWHObEIbZJt1E80HyukEUqB0JXYC65vzut6c2zFJJaeAjKyuO3kUZ1JK3 tcVEGhAEMe2SHPBB0rAd05jEAxNDQY2hCG6GHlAU= Date: Thu, 15 Apr 2021 13:33:10 -0700 From: Andrew Morton To: =?ISO-8859-1?Q?"Christian_K=F6nig"?= Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, vbabka@suse.cz, daniel@ffwll.ch, ray.huang@amd.com Subject: Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2 Message-Id: <20210415133310.1ee9df70a9eb887be937c3a3@linux-foundation.org> In-Reply-To: <20210415115624.2904-2-christian.koenig@amd.com> References: <20210415115624.2904-1-christian.koenig@amd.com> <20210415115624.2904-2-christian.koenig@amd.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 76B3140002D2 X-Stat-Signature: w3tsgwdbp5jy1ujwpbxux3ojqi8g6w9r Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf10; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618518788-565681 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 15 Apr 2021 13:56:24 +0200 "Christian K=F6nig" wrote: > @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool) > for (j =3D 0; j < MAX_ORDER; ++j) > ttm_pool_type_fini(&pool->caching[i].orders[j]); > } > + > + /* We removed the pool types from the LRU, but we need to also make sure > + * that no shrinker is concurrently freeing pages from the pool. > + */ > + sync_shrinkers(); It isn't immediately clear to me how this works. ttm_pool_fini() has already freed all the pages hasn't it? So why would it care if some shrinkers are still playing with the pages? Or is it the case that ttm_pool_fini() is assuming that there will be some further action against these pages, which requires that shrinkers no longer be accessing the pages and which further assumes that future shrinker invocations will not be able to look up these pages? IOW, a bit more explanation about the dynamics here would help!