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 9097BC433DB for ; Tue, 23 Mar 2021 12:01:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D99186191C for ; Tue, 23 Mar 2021 12:01:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D99186191C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 521646B017D; Tue, 23 Mar 2021 08:01:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F87C6B017F; Tue, 23 Mar 2021 08:01:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3999B6B0180; Tue, 23 Mar 2021 08:01:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 1FBDE6B017D for ; Tue, 23 Mar 2021 08:01:39 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AFC7587C6 for ; Tue, 23 Mar 2021 12:01:38 +0000 (UTC) X-FDA: 77950999476.04.0FBD584 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf05.hostedemail.com (Postfix) with ESMTP id 5FC7EE16E22A for ; Tue, 23 Mar 2021 12:00:33 +0000 (UTC) Received: by mail-wm1-f47.google.com with SMTP id g20so10897688wmk.3 for ; Tue, 23 Mar 2021 05:00:33 -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:content-transfer-encoding :in-reply-to; bh=FVtKo5jWx+3SADF4ukoqEH4dm/CLnkXyOS/C8B/YN74=; b=FERWySWSOM/W7EFVRKsXbUsUBktYQ2g0wNeTUma34kmuD7xrWuD5y5ZBNOLeX6s/uQ YmE7WR3db7FJTJJkLhvV1yap0Ehurf1atRYcqIgno5djdYvn69PUGwB1ZSNfdiKgFTV3 2KWGpisExOBGA2hZ68BtWc06f7AQYDbgCclhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=FVtKo5jWx+3SADF4ukoqEH4dm/CLnkXyOS/C8B/YN74=; b=WV88HlPCoxE+mSpMDEyl3a0+MaE6xTwXq1FQeIA72vQBuODEN0vEDpLq5u9XgkTHlY 9tyd93AB2WTVD4svJhbNJ2XKq6y5dlVnfxuwmRrGZGmkXuI4v9TR+LrbMWWtTX6eebMN sz/kkAkWlMO517dxsAWJBUx1APUDh1L0Eal5XJbjjfF3RIGCMYximwWBxxYOHEa/II/O PDqGJ5Ao755t2WdPHRllO142qWw4fsukkgXrkeONouUEbrfXEnV6DbUDMr0J6nnOerBq V9vVQ2HPrheLLmc7eh4735M+7LXNBHWOZeioyuTY/FmJnZaxAGwxd0zBBwUrSt+9ox6O pA5g== X-Gm-Message-State: AOAM531r+RsGOcu/snkdbsAMc5Flsr7ibq8j7ySYcw+2j9oGvjlGtgIQ LgnaKPEuUVIInLBEgo/C4GqW0A== X-Google-Smtp-Source: ABdhPJxARHVEyqF19UyUbqTXsQiNOuv2yKBtCTkGaA8qrztykEOb1q+KlOZakO4Qh5lWRW5aoJHbyg== X-Received: by 2002:a1c:6243:: with SMTP id w64mr454513wmb.0.1616500832352; Tue, 23 Mar 2021 05:00:32 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id k24sm2213978wmr.48.2021.03.23.05.00.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 05:00:31 -0700 (PDT) Date: Tue, 23 Mar 2021 13:00:29 +0100 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Michal Hocko , 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: Mail-Followup-To: Christian =?iso-8859-1?Q?K=F6nig?= , Michal Hocko , Matthew Wilcox , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu 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-Operating-System: Linux phenom 5.7.0-1-amd64 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5FC7EE16E22A X-Stat-Signature: 5zmcdb9og3d83rjdmn45d55cbi4t7mir Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mail-wm1-f47.google.com; client-ip=209.85.128.47 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616500833-451261 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, Mar 23, 2021 at 12:51:13PM +0100, 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. Yeah this is only for testing. There's two ways to test your shrinker: - drive system agains the OOM wall, deal with lots of unrelated hangs and issues. Aside from this takes postively forever, which is not good if you want CI turn-around time measured in "coffee breaks" as time unit. - have a debugfs file which reconstructs the calling context of direct reclaim sufficiently for lockdep to do its thing, and then test just your shrinker in isolation, without crashing your CI machines or even hurting it much. Only one of these options is actually practical. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch