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=-7.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, 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 3F5C7C433ED for ; Fri, 16 Apr 2021 07:08:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C912661153 for ; Fri, 16 Apr 2021 07:08:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C912661153 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 463CD6B0036; Fri, 16 Apr 2021 03:08:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4479C6B006C; Fri, 16 Apr 2021 03:08:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B48C6B0070; Fri, 16 Apr 2021 03:08:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id 0A62E6B0036 for ; Fri, 16 Apr 2021 03:08:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B70641802851F for ; Fri, 16 Apr 2021 07:08:56 +0000 (UTC) X-FDA: 78037353072.07.23E1B71 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf19.hostedemail.com (Postfix) with ESMTP id DD4F990009FB for ; Fri, 16 Apr 2021 07:08:38 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id w18so31068922edc.0 for ; Fri, 16 Apr 2021 00:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=zLSMvZYRAJCsk2Rs4S2rsxdlqP0N63/bvG4UtBJlhds=; b=BlfiJ62lVmCMYByn7WvrksbbVI6TDARHp3g2O1W3ZtQwmxayq62Kf5FE0ajOQhHB26 htlN704WKAY3fwWT25ySYXp46TeheqfnPYqTn7LL1Xm8/rvCPRrTHFX5lf0nkKQKh8P+ 15pSu5V0cHZrpjn83WWFePMOoOwlVnVlNoYNKRbxW5XEqi4ifSYHOIfL0H2hapsMAUNx CaBM7Jv9Pdmy8X1L123AXZniNoRhXalwQGdR3SDfq9od/K6Etk3U5GE99+JxY5Igv8+X pojj+Ob30ktvFVtClekEkCGrvmyeohvQUScQlV+EgfQQGqhkCz8+8DWzN43Ler/Ye98W IfFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=zLSMvZYRAJCsk2Rs4S2rsxdlqP0N63/bvG4UtBJlhds=; b=hED7U+ZCxSQjQ2LqAZ0liwtfCm+tgMO5Amhr0U7HCqWjhCTI5+dKZ+d41B5ol00cuV 9/uflMP2P8E5b/FYWDbHKNEUTukAddVSx/K7GlCNTOCSeXZ/eJAzOaJbnP10WXAC3Xte LCizJt/v1otOTicmBOdbsQ4Avb6XDtJBJ1VGc2XyTw12C7zJ/4aDOHYn1bNuUgsQ6BCR 5iWLKqKrwEkeH/vlwx2HOr9GLRjCkcol9W7dFjE2NYQczmzfTGrElrUMxah47tJONhoY BaO2qqpEEq9eEqgU97kKc9a51RmsKA9aRadNiQqtWL52xlEEGuUhHoT05NeBkw7Eg8/j t9jA== X-Gm-Message-State: AOAM5332nFb5zzjVBHfQ8unM65d9cmtHHHE5n8fBprYiPC58nNUihiHk U+sE9i93l3suA1HvWhmIVJ8= X-Google-Smtp-Source: ABdhPJydJ7xvzJS0k7fG4gTWodX4tiWHFMzTnM+NC5HYG9Xb+seCqYMDtLNm+BvO9A97hGceLRSCXQ== X-Received: by 2002:a05:6402:4405:: with SMTP id y5mr8598888eda.32.1618556935191; Fri, 16 Apr 2021 00:08:55 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:c122:98c9:2964:3d64? ([2a02:908:1252:fb60:c122:98c9:2964:3d64]) by smtp.gmail.com with ESMTPSA id k9sm3405159eje.102.2021.04.16.00.08.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 00:08:54 -0700 (PDT) Subject: Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2 To: Andrew Morton 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 References: <20210415115624.2904-1-christian.koenig@amd.com> <20210415115624.2904-2-christian.koenig@amd.com> <20210415133310.1ee9df70a9eb887be937c3a3@linux-foundation.org> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <57572373-d68c-80de-7f9e-c04239d1b050@gmail.com> Date: Fri, 16 Apr 2021 09:08:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210415133310.1ee9df70a9eb887be937c3a3@linux-foundation.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DD4F990009FB X-Stat-Signature: yye1us6secw7jidzbtcx7aazxa1bsstm Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mail-ed1-f46.google.com; client-ip=209.85.208.46 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618556918-577124 Content-Transfer-Encoding: quoted-printable 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: Am 15.04.21 um 22:33 schrieb Andrew Morton: > On Thu, 15 Apr 2021 13:56:24 +0200 "Christian K=C3=B6nig" 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? Yes ttm_pool_fini() has freed up all pages which had been in the pool=20 when the function was called. But the problem is it is possible that a parallel running shrinker has=20 taken a page from the pool and is in the process of freeing it up. When I return here the pool structure and especially the device=20 structure are freed while the parallel running shrinker is still using th= em. I could go for a design where we have one shrinker per device instead,=20 but that would put a bit to much pressure on the pool in my opinion. > 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! Sorry, I'm not a native speaker of English and sometimes still have a=20 hard time explaining things. Regards, Christian.