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 E1823C433C1 for ; Tue, 23 Mar 2021 07:38:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 51C71619C4 for ; Tue, 23 Mar 2021 07:38:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51C71619C4 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 A1ACC6B00D7; Tue, 23 Mar 2021 03:38:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C9EB6B00D8; Tue, 23 Mar 2021 03:38:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86B1F6B00DB; Tue, 23 Mar 2021 03:38:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 66D896B00D7 for ; Tue, 23 Mar 2021 03:38:47 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 23F48180AD820 for ; Tue, 23 Mar 2021 07:38:47 +0000 (UTC) X-FDA: 77950337094.27.0306FA6 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf19.hostedemail.com (Postfix) with ESMTP id DBC2590009D6 for ; Tue, 23 Mar 2021 07:38:45 +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=1616485125; 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=ofPdbLGiOv4t4glajDJiQOBAXsq/hbLdis6yZwHlhBg=; b=mDTbOZXOo1pjW69S7Rhqr3O0HUnTFZK692Xd6c6Kkw2rAh+eVm2wN8ttIXEQPjhnY8C3Z+ Jwhq2L5om4GpvS1ahdVWBo+B3gbxmA60cqA9za2A8zGl6y4RP2mz6VdXqVXoz5TELQhGCu lL8TRKSvQRXtlkiC4Ak6ssTSc5DeF4g= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 13332ACBF; Tue, 23 Mar 2021 07:38:45 +0000 (UTC) Date: Tue, 23 Mar 2021 08:38:33 +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: <2831bfcc-140e-dade-1f50-a6431e495e9d@gmail.com> <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <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: uadutdwm843pjau19dt8gkbtmxyyzuhc X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DBC2590009D6 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616485125-727743 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 Mon 22-03-21 20:34:25, Christian K=F6nig wrote: > Am 22.03.21 um 18:02 schrieb Daniel Vetter: > > On Mon, Mar 22, 2021 at 5:06 PM Michal Hocko wrote: > > > On Mon 22-03-21 14:05:48, Matthew Wilcox wrote: > > > > On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote: > > > > > On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian K=F6nig wro= te: > > > > > > Am 20.03.21 um 14:17 schrieb Daniel Vetter: > > > > > > > On Sat, Mar 20, 2021 at 10:04 AM Christian K=F6nig > > > > > > > wrote: > > > > > > > > Am 19.03.21 um 20:06 schrieb Daniel Vetter: > > > > > > > > > On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian K=F6= nig wrote: > > > > > > > > > > Am 19.03.21 um 18:52 schrieb Daniel Vetter: > > > > > > > > > > > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian= K=F6nig wrote: > > > > > > > > > > > > Don't print a warning when we fail to allocate a = page for swapping things out. > > > > > > > > > > > >=20 > > > > > > > > > > > > Also rely on memalloc_nofs_save/memalloc_nofs_res= tore instead of GFP_NOFS. > > > > > > > > > > > Uh this part doesn't make sense. Especially since y= ou only do it for the > > > > > > > > > > > debugfs file, not in general. Which means you've ju= st completely broken > > > > > > > > > > > the shrinker. > > > > > > > > > > Are you sure? My impression is that GFP_NOFS should n= ow work much more out > > > > > > > > > > of the box with the memalloc_nofs_save()/memalloc_nof= s_restore(). > > > > > > > > > Yeah, if you'd put it in the right place :-) > > > > > > > > >=20 > > > > > > > > > But also -mm folks are very clear that memalloc_no*() f= amily is for dire > > > > > > > > > situation where there's really no other way out. For an= ything where you > > > > > > > > > know what you're doing, you really should use explicit = gfp flags. > > > > > > > > My impression is just the other way around. You should tr= y to avoid the > > > > > > > > NOFS/NOIO flags and use the memalloc_no* approach instead= . > > > > > > > Where did you get that idea? > > > > > > Well from the kernel comment on GFP_NOFS: > > > > > >=20 > > > > > > * %GFP_NOFS will use direct reclaim but will not use any fi= lesystem > > > > > > interfaces. > > > > > > * Please try to avoid using this flag directly and instead = use > > > > > > * memalloc_nofs_{save,restore} to mark the whole scope whic= h > > > > > > cannot/shouldn't > > > > > > * recurse into the FS layer with a short explanation why. A= ll allocation > > > > > > * requests will inherit GFP_NOFS implicitly. > > > > > Huh that's interesting, since iirc Willy or Dave told me the op= posite, and > > > > > the memalloc_no* stuff is for e.g. nfs calling into network lay= er (needs > > > > > GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO = I think). > > > > >=20 > > > > > Adding them, maybe I got confused. > > > > My impression is that the scoped API is preferred these days. > > > >=20 > > > > https://www.kernel.org/doc/html/latest/core-api/gfp_mask-from-fs-= io.html > > > >=20 > > > > I'd probably need to spend a few months learning the DRM subsyste= m to > > > > have a more detailed opinion on whether passing GFP flags around = explicitly > > > > or using the scope API is the better approach for your situation. > > > yes, in an ideal world we would have a clearly defined scope of the > > > reclaim recursion wrt FS/IO associated with it. I've got back to > > > https://lore.kernel.org/amd-gfx/20210319140857.2262-1-christian.koe= nig@amd.com/ > > > and there are two things standing out. Why does ttm_tt_debugfs_shri= nk_show > > > really require NOFS semantic? And why does it play with > > > fs_reclaim_acquire? > > It's our shrinker. shrink_show simply triggers that specific shrinker > > asking it to shrink everything it can, which helps a lot with testing > > without having to drive the entire system against the OOM wall. Yes I figured that much. But... > > fs_reclaim_acquire is there to make sure lockdep understands that thi= s > > 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... =20 > To summarize the debugfs code is basically to test if that stuff really > works with GFP_NOFS. What do you mean by testing GFP_NOFS. Do you mean to test that GFP_NOFS context is sufficiently powerful to reclaim enough objects due to some internal constrains? > My only concern is that if I could rely on memalloc_no* being used we c= ould > optimize this quite a bit further. Yes you can use the scope API and you will be guaranteed that _any_ allocation from the enclosed context will inherit GFP_NO* semantic. --=20 Michal Hocko SUSE Labs