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=-4.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 CA60DC433C1 for ; Tue, 23 Mar 2021 11:51:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D230601FF for ; Tue, 23 Mar 2021 11:51:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D230601FF 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 D1C9E6B0171; Tue, 23 Mar 2021 07:51:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCDE26B0173; Tue, 23 Mar 2021 07:51:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B46176B0174; Tue, 23 Mar 2021 07:51:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0109.hostedemail.com [216.40.44.109]) by kanga.kvack.org (Postfix) with ESMTP id 949C36B0171 for ; Tue, 23 Mar 2021 07:51:16 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 43E65180585C3 for ; Tue, 23 Mar 2021 11:51:16 +0000 (UTC) X-FDA: 77950973352.02.9C74456 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf14.hostedemail.com (Postfix) with ESMTP id 34DE7C0007D3 for ; Tue, 23 Mar 2021 11:51:14 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id w3so26595148ejc.4 for ; Tue, 23 Mar 2021 04:51:15 -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=JWCHWFwsG8yAzV03OTUOhh2O9iC7eym1dVNKWhgZZjs=; b=BRTtEir0vV8VjibQFJUw7vOLkJMfeYABsba+9SJWPRyNEW8i1OEMB5kkNp534VlNs+ 7sl2dGOV4/5Wd92Djj1tf3r57WKsxQF3RNzMnx6lpXTrMS5/D8YCLEA9/tzlqWd/L+QC GSWYzvDMhEr1uwmhiocBqVoBQ66mtCbTs30QgSHO99PXKTwejiIhzk/jgXVeJj6v0CFu pRMZ79du/2Riy1OY4rr0KU6ocz4I8qtzsXKt7hw8QUZ9cwVFUo7QBNSCfLnTf0c19nZd 6qYdLvj6mfPUKEnNseIZUsG5GwL9ovOIi6JGlSC2KZvK9eiYTrT4RZVtmUnSOo/Tw5XH OXYQ== 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=JWCHWFwsG8yAzV03OTUOhh2O9iC7eym1dVNKWhgZZjs=; b=VuKF5FMJXwO6MTlNgwO8tIu2dwSQadhFzP/RT25LMiDVyyMRK4zYu4NntYM/Xfxfdm QP0tOi8NhAdB8FCDdgYZxya34+r1MPuu9aKe4mZ+5wyQ5f4cQ9hu5ZqZwL/infyHlqbH IABQbGTR5HpaCnBKp9QDp5857+SW4TtQbqvVnJ4xJfNeTDnh5gghx7W4/OA+YwjxHK/3 RMaPJISYGtDd6NvS5tG5GHsFiFcikay5udjSx7n+KhQ+iJGkuQOw71ZtSTDXl9UcS15y DoxLafNqiR15MgFRjbHNjvBhfNFOFKI4qohDcBx0YpQ/q+MkbXoqw1aAf4V/dJvtbecv ZvRw== X-Gm-Message-State: AOAM531LcxVa02r3dFSWP0fE+i6XLBVjzOEdEkBw6qfypNfGFZL0KEa+ Rv02pTvUDoYyySeLS2AxMbQ= X-Google-Smtp-Source: ABdhPJxsrabBoa7M9oiVWkVeAIwKM+ydfyCpTsx+1w70kNyHxgoKtcDAjaVQyNDPYn6G6RLmhgt3yQ== X-Received: by 2002:a17:906:311a:: with SMTP id 26mr4430193ejx.395.1616500274813; Tue, 23 Mar 2021 04:51:14 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:fdcd:4dd1:a1af:a7ec? ([2a02:908:1252:fb60:fdcd:4dd1:a1af:a7ec]) by smtp.gmail.com with ESMTPSA id p9sm12666884eds.66.2021.03.23.04.51.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Mar 2021 04:51:14 -0700 (PDT) Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure To: Michal Hocko , Daniel Vetter Cc: Matthew Wilcox , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu References: <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <20210322140548.GN1719932@casper.infradead.org> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Tue, 23 Mar 2021 12:51:13 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 34DE7C0007D3 X-Stat-Signature: 1tzjrwrp9g3wiqadjqpbb34sd9uuirdu Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-ej1-f50.google.com; client-ip=209.85.218.50 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616500274-366945 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 23.03.21 um 12:46 schrieb Michal Hocko: > On Tue 23-03-21 12:28:20, Daniel Vetter wrote: >> On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > [...] >>>>> fs_reclaim_acquire is there to make sure lockdep understands that this >>>>> is a shrinker and that it checks all the dependencies for us like if >>>>> we'd be in real reclaim. There is some drop caches interfaces in proc >>>>> iirc, but those drop everything, and they don't have the fs_reclaim >>>>> annotations to teach lockdep about what we're doing. >>> ... I really do not follow this. You shouldn't really care whether this >>> is a reclaim interface or not. Or maybe I just do not understand this... >> We're heavily relying on lockdep and fs_reclaim to make sure we get it all >> right. So any drop caches interface that isn't wrapped in fs_reclaim >> context is kinda useless for testing. Plus ideally we want to only hit our >> own paths, and not trash every other cache in the system. Speed matters in >> CI. > But what is special about this path to hack around and make it pretend > it is part of the fs reclaim path? That's just to teach lockdep that there is a dependency. In other words we pretend in the debugfs file that it is part of the fs reclaim path to check for the case when it really becomes part of the fs reclaim path. Regards, Christian.