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 10C6DC433E0 for ; Tue, 23 Mar 2021 11:28:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DC68619B8 for ; Tue, 23 Mar 2021 11:28:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DC68619B8 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 C251A6B0162; Tue, 23 Mar 2021 07:28:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFC036B0164; Tue, 23 Mar 2021 07:28:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9BB66B0165; Tue, 23 Mar 2021 07:28:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 8D5C76B0162 for ; Tue, 23 Mar 2021 07:28:25 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 40230906F for ; Tue, 23 Mar 2021 11:28:25 +0000 (UTC) X-FDA: 77950915770.06.857C082 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf24.hostedemail.com (Postfix) with ESMTP id 3036EA0009E4 for ; Tue, 23 Mar 2021 11:28:23 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id w203-20020a1c49d40000b029010c706d0642so945488wma.0 for ; Tue, 23 Mar 2021 04:28:23 -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=D+NyPjsJ+1GW7mDMp5MrVh/C5QY0YA2fly1lgVcTiAk=; b=MxJ2KV2cgA5nNI+zvJlpHQd9qdF7OeZ/97M/ZIH7+QuKjpxqgEfvZzGEWdrOBsuxV4 c1qoZ7ouegY596ymeKbbrAIw3ir2EWvKrq7bvyq4DhBHQwjQW62mEV4wsufiTa+QdHZT MkH7/RFpIvdW/rrAArbN5EGAftbWn7qYsza7o= 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=D+NyPjsJ+1GW7mDMp5MrVh/C5QY0YA2fly1lgVcTiAk=; b=iKAYIWIPobSbrbkqFW4qhgxVF3RIe81+F2BAgZdb8agRy4MnuAeTTlHtdZ3uLyJGzb MGUMFGeCFA9fCNhWkjGk+OezXZ2GUwjVWNkzdxdbSZ+IIVN/PKr0LSnCUhjhS+qxwMf0 /vzaif9k9WVtPH4HM4Sb+jy+qIJAhPT5wxsAHQGtaWMUbdPln32qMaNQMT7JusFqn0W7 EaZI5Y6lKzY1bGIG35H68V4ynvwW/zI8MeUhrZp0hdhIPx6rDk+p5afE9OYg5mQ9TR4I DjL60oOHu8sPMtTm1DmzvJkOQH++FeHTo0qPX5TG7wgA5ivqq7QbkOS6/98FQW7/VpSl 3TPg== X-Gm-Message-State: AOAM5303SLbJyOCwb8qEsfqykuMoSzs+8cWfV0QHmuEBuhgGpIQzX+aF ssjblCZTy2XHaArPQHaHGSbh6Q== X-Google-Smtp-Source: ABdhPJxKAjL5w3e8FQp+Ic49cpESgWVuGaVDBFqAJucj8k1zAMnKthjdGYROFZOmVrOFhaVxm8SE1g== X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr2838646wmk.53.1616498902785; Tue, 23 Mar 2021 04:28:22 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id c11sm24060039wrm.67.2021.03.23.04.28.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 04:28:21 -0700 (PDT) Date: Tue, 23 Mar 2021 12:28:20 +0100 From: Daniel Vetter To: Michal Hocko Cc: Christian =?iso-8859-1?Q?K=F6nig?= , 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: Michal Hocko , Christian =?iso-8859-1?Q?K=F6nig?= , 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> 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: 3036EA0009E4 X-Stat-Signature: 7ipjwp38dcogsirqy1ismme3uni18bgb Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail-wm1-f51.google.com; client-ip=209.85.128.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616498903-764224 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 08:38:33AM +0100, Michal Hocko wrote: > 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 wrot= e: > > > > 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 w= rote: > > > > > > > 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= =F6nig wrote: > > > > > > > > > > > Am 19.03.21 um 18:52 schrieb Daniel Vetter: > > > > > > > > > > > > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christi= an 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_r= estore instead of GFP_NOFS. > > > > > > > > > > > > Uh this part doesn't make sense. Especially since= you only do it for the > > > > > > > > > > > > debugfs file, not in general. Which means you've = just completely broken > > > > > > > > > > > > the shrinker. > > > > > > > > > > > Are you sure? My impression is that GFP_NOFS should= now work much more out > > > > > > > > > > > of the box with the memalloc_nofs_save()/memalloc_n= ofs_restore(). > > > > > > > > > > Yeah, if you'd put it in the right place :-) > > > > > > > > > >=20 > > > > > > > > > > But also -mm folks are very clear that memalloc_no*()= family is for dire > > > > > > > > > > situation where there's really no other way out. For = anything where you > > > > > > > > > > know what you're doing, you really should use explici= t gfp flags. > > > > > > > > > My impression is just the other way around. You should = try to avoid the > > > > > > > > > NOFS/NOIO flags and use the memalloc_no* approach inste= ad. > > > > > > > > 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 = filesystem > > > > > > > interfaces. > > > > > > > * Please try to avoid using this flag directly and instea= d use > > > > > > > * memalloc_nofs_{save,restore} to mark the whole scope wh= ich > > > > > > > cannot/shouldn't > > > > > > > * recurse into the FS layer with a short explanation why.= All allocation > > > > > > > * requests will inherit GFP_NOFS implicitly. > > > > > > Huh that's interesting, since iirc Willy or Dave told me the = opposite, and > > > > > > the memalloc_no* stuff is for e.g. nfs calling into network l= ayer (needs > > > > > > GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOI= O 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-f= s-io.html > > > > >=20 > > > > > I'd probably need to spend a few months learning the DRM subsys= tem to > > > > > have a more detailed opinion on whether passing GFP flags aroun= d explicitly > > > > > or using the scope API is the better approach for your situatio= n. > > > > yes, in an ideal world we would have a clearly defined scope of t= he > > > > reclaim recursion wrt FS/IO associated with it. I've got back to > > > > https://lore.kernel.org/amd-gfx/20210319140857.2262-1-christian.k= oenig@amd.com/ > > > > and there are two things standing out. Why does ttm_tt_debugfs_sh= rink_show > > > > really require NOFS semantic? And why does it play with > > > > fs_reclaim_acquire? > > > It's our shrinker. shrink_show simply triggers that specific shrink= er > > > asking it to shrink everything it can, which helps a lot with testi= ng > > > without having to drive the entire system against the OOM wall. >=20 > Yes I figured that much. But... >=20 > > > fs_reclaim_acquire is there to make sure lockdep understands that t= his > > > is a shrinker and that it checks all the dependencies for us like i= f > > > we'd be in real reclaim. There is some drop caches interfaces in pr= oc > > > iirc, but those drop everything, and they don't have the fs_reclaim > > > annotations to teach lockdep about what we're doing. >=20 > ... 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 al= l 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 ou= r own paths, and not trash every other cache in the system. Speed matters i= n CI. > > To summarize the debugfs code is basically to test if that stuff real= ly > > works with GFP_NOFS. >=20 > 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? >=20 > > My only concern is that if I could rely on memalloc_no* being used we= could > > optimize this quite a bit further. >=20 > Yes you can use the scope API and you will be guaranteed that _any_ > allocation from the enclosed context will inherit GFP_NO* semantic. I think this is where I don't get yet what Christian tries to do: We really shouldn't do different tricks and calling contexts between direct reclaim and kswapd reclaim. Otherwise very hard to track down bugs are pretty much guaranteed. So whether we use explicit gfp flags or the context apis, result is exactly the same. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch