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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 7443AC433C1 for ; Tue, 23 Mar 2021 12:06:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DF29F61994 for ; Tue, 23 Mar 2021 12:06:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF29F61994 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 569D56B0183; Tue, 23 Mar 2021 08:06:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F35D6B0185; Tue, 23 Mar 2021 08:06:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A9E46B0186; Tue, 23 Mar 2021 08:06:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id 1A55C6B0183 for ; Tue, 23 Mar 2021 08:06:01 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D4EC78249980 for ; Tue, 23 Mar 2021 12:06:00 +0000 (UTC) X-FDA: 77951010480.04.A83B8C8 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf18.hostedemail.com (Postfix) with ESMTP id C0BB6200025C for ; Tue, 23 Mar 2021 12:05:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616501159; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ubkNv0IBq9hFDX1nFQfvcQDGdBJM58OvXcv+fHHXwRE=; b=Q0cBfWAKpz0mIo+FE3mbbdmuM+ij28enHdJQhee5v9eHvN6yRojHDoNMMQsc2l4gP6DCSY X0Edvz00l2QWoysRCcVX7Y/aPFsq5YyNfjbvgpb3bNq/VJqCMOZaNjxj9raYIOAwTRC2RY z1O+TdpGTCboqRQOWIx9Ip3UdoKhalo= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3C003AD6D; Tue, 23 Mar 2021 12:05:59 +0000 (UTC) Date: Tue, 23 Mar 2021 13:05:58 +0100 From: Michal Hocko To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Daniel Vetter , Matthew Wilcox , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure Message-ID: References: <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Stat-Signature: 97cm6uxxy7yngd3h58kazpgok75zdo89 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C0BB6200025C Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616501159-284369 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: On Tue 23-03-21 12:51:13, Christian K=F6nig wrote: >=20 >=20 > 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_r= eclaim > > > > > > annotations to teach lockdep about what we're doing. > > > > ... I really do not follow this. You shouldn't really care whethe= r 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_reclai= m > > > 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 mat= ters in > > > CI. > > But what is special about this path to hack around and make it preten= d > > it is part of the fs reclaim path? >=20 > That's just to teach lockdep that there is a dependency. >=20 > 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 f= s > reclaim path. OK, our emails crossed and I can see your response only after replying to your other email. OK, this makes more sense now. But as pointed in other email this will likely not do what you think. Let's continue discussing in the other subthread to reduce the further confusion. --=20 Michal Hocko SUSE Labs