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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 25EE1C433C1 for ; Tue, 23 Mar 2021 11:47:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2D69619BF for ; Tue, 23 Mar 2021 11:47:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2D69619BF 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 160E26B016C; Tue, 23 Mar 2021 07:47:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 111E76B016D; Tue, 23 Mar 2021 07:47:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF4026B016E; Tue, 23 Mar 2021 07:47:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id D6E266B016C for ; Tue, 23 Mar 2021 07:47:00 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 81B6418075DCA for ; Tue, 23 Mar 2021 11:47:00 +0000 (UTC) X-FDA: 77950962600.01.4992F6D Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf18.hostedemail.com (Postfix) with ESMTP id 739F0200024E for ; Tue, 23 Mar 2021 11:46: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=1616500018; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tVCFDSW+Wg+Vv3qM3o+3xBVx/wVrj6oBYyLDMD5T3p0=; b=H0klc++nQTU56KJLqJHExfutlIiECMjC7FmYaidwh/64jI6kyCH5SfD1CdgRjN4LmmsGHz 2HiA6ZSDwvpsXrxCWfAg/VYuHojKhxt6od88uI+dNPP9XQ4OXxN5BqtimGsWlQUg9kG5Nr fWfotsS5xltn1xbTLh4C8OFoPie6wgM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9C869AE42; Tue, 23 Mar 2021 11:46:58 +0000 (UTC) Date: Tue, 23 Mar 2021 12:46:57 +0100 From: Michal Hocko To: Daniel Vetter Cc: Christian =?iso-8859-1?Q?K=F6nig?= , 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: <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 739F0200024E X-Stat-Signature: fos1u9i7bjohdg5rdbu53ncw7hzp54qj 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: 1616500019-4035 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: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? -- Michal Hocko SUSE Labs 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 CFAD0C433DB for ; Tue, 23 Mar 2021 11:47:01 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 824D3619B1 for ; Tue, 23 Mar 2021 11:47:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 824D3619B1 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E6D166E8C6; Tue, 23 Mar 2021 11:47:00 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 44CC96E8C6; Tue, 23 Mar 2021 11:47:00 +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=1616500018; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tVCFDSW+Wg+Vv3qM3o+3xBVx/wVrj6oBYyLDMD5T3p0=; b=H0klc++nQTU56KJLqJHExfutlIiECMjC7FmYaidwh/64jI6kyCH5SfD1CdgRjN4LmmsGHz 2HiA6ZSDwvpsXrxCWfAg/VYuHojKhxt6od88uI+dNPP9XQ4OXxN5BqtimGsWlQUg9kG5Nr fWfotsS5xltn1xbTLh4C8OFoPie6wgM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9C869AE42; Tue, 23 Mar 2021 11:46:58 +0000 (UTC) Date: Tue, 23 Mar 2021 12:46:57 +0100 From: Michal Hocko To: Daniel Vetter Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure Message-ID: References: <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Wilcox , Christian =?iso-8859-1?Q?K=F6nig?= , amd-gfx list , Linux MM , dri-devel , Dave Chinner , Leo Liu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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? -- Michal Hocko SUSE Labs _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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 25BD6C433E0 for ; Tue, 23 Mar 2021 12:47:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C932C619B7 for ; Tue, 23 Mar 2021 12:47:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C932C619B7 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D25D06E123; Tue, 23 Mar 2021 12:47:48 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 44CC96E8C6; Tue, 23 Mar 2021 11:47:00 +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=1616500018; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tVCFDSW+Wg+Vv3qM3o+3xBVx/wVrj6oBYyLDMD5T3p0=; b=H0klc++nQTU56KJLqJHExfutlIiECMjC7FmYaidwh/64jI6kyCH5SfD1CdgRjN4LmmsGHz 2HiA6ZSDwvpsXrxCWfAg/VYuHojKhxt6od88uI+dNPP9XQ4OXxN5BqtimGsWlQUg9kG5Nr fWfotsS5xltn1xbTLh4C8OFoPie6wgM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9C869AE42; Tue, 23 Mar 2021 11:46:58 +0000 (UTC) Date: Tue, 23 Mar 2021 12:46:57 +0100 From: Michal Hocko To: Daniel Vetter Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure Message-ID: References: <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 23 Mar 2021 12:47:47 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Wilcox , Christian =?iso-8859-1?Q?K=F6nig?= , amd-gfx list , Linux MM , dri-devel , Dave Chinner , Leo Liu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" 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? -- Michal Hocko SUSE Labs _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx