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,URIBL_BLOCKED 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 72F83C433DB for ; Mon, 22 Mar 2021 17:02:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E831A61998 for ; Mon, 22 Mar 2021 17:02:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E831A61998 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 5DFCC6B00F4; Mon, 22 Mar 2021 13:02:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58FAC6B00F6; Mon, 22 Mar 2021 13:02:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E3296B00F7; Mon, 22 Mar 2021 13:02:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 1D7BC6B00F4 for ; Mon, 22 Mar 2021 13:02:29 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9D9909423 for ; Mon, 22 Mar 2021 17:02:28 +0000 (UTC) X-FDA: 77948128776.27.F09777C Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by imf16.hostedemail.com (Postfix) with ESMTP id 231A380192E9 for ; Mon, 22 Mar 2021 17:02:22 +0000 (UTC) Received: by mail-ot1-f42.google.com with SMTP id t23-20020a0568301e37b02901b65ab30024so16650104otr.4 for ; Mon, 22 Mar 2021 10:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ow15AyWWo9pzUtxBqr+0MCCuYbydO4LdQhm9i3QGpOM=; b=dI7hYScDvigTwHtnohhjBIkI+bbfsi+Y2Y+9caiaj//FDbAxuUSCpm9gRDaf8zljKm 71pVR2Pz3wtFVEaXAbURSrcU/s0RCBSUaq4bo5J7Tfp3fweChjof8y7euCz+rLDUpC1q r18gWi3zea3/27yRw2CERPn9Z8m11UuoYsImQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ow15AyWWo9pzUtxBqr+0MCCuYbydO4LdQhm9i3QGpOM=; b=C7njAPbxPEzujQIEAgP+9CBwtKsIhaHo0DNVIaLAFNqrEc4gbxmlwXiLeZ7jYUdtjX gAFoJ6j7jcU3ZZQBq+mD5787hW9aJxZY/CiHemrVWjLetM0iQhoVcj6B3VlmIwQuMRGl efmHq8CNmeMP9VT8SpQ7NFcBbBl6GNjoCVhiFGBZizNnFWprk19D3udGBf4BKFUid3Og uWHNHz+2q6SlU87HTKudlI8/jncFa8tds4thBx6CdMiTumsOrFE5+u9HBrgO93kr89Z4 zokjOqhB5tlql0PygOxfagP1bKeR6/MIbx/jnt0qhWP2J1XD7J+TycCiqtM3LKip1KoN kfKA== X-Gm-Message-State: AOAM530E5HL3chPliISmZXBPq/RpxqL3nA6fha+oFyk1B1G2bHtxQS1U uWVhzw71hQXzYmyqdDUlNY5FTg/OQ3JRt0oiMJW1tw== X-Google-Smtp-Source: ABdhPJxMfkDJpJLIrH9tErjhqT3yLQM23cMXRDpi+Efl0HlYE7pmL8by9hDnkLUCk7IIm3o2Ax9TDOCwl9aeIlW724c= X-Received: by 2002:a9d:7b4e:: with SMTP id f14mr715495oto.281.1616432540363; Mon, 22 Mar 2021 10:02:20 -0700 (PDT) MIME-Version: 1.0 References: <20210319140857.2262-1-christian.koenig@amd.com> <2831bfcc-140e-dade-1f50-a6431e495e9d@gmail.com> <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com> <20210322140548.GN1719932@casper.infradead.org> In-Reply-To: From: Daniel Vetter Date: Mon, 22 Mar 2021 18:02:09 +0100 Message-ID: Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure To: Michal Hocko Cc: Matthew Wilcox , =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 44yje4hxm8ug1m3s3c96ca7okfgaqa9n X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 231A380192E9 Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf16; identity=mailfrom; envelope-from=""; helo=mail-ot1-f42.google.com; client-ip=209.85.210.42 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616432542-629647 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, 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=C3=B6nig wrote: > > > > Am 20.03.21 um 14:17 schrieb Daniel Vetter: > > > > > On Sat, Mar 20, 2021 at 10:04 AM Christian K=C3=B6nig > > > > > wrote: > > > > > > Am 19.03.21 um 20:06 schrieb Daniel Vetter: > > > > > > > On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian K=C3=B6ni= g wrote: > > > > > > > > Am 19.03.21 um 18:52 schrieb Daniel Vetter: > > > > > > > > > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian K=C3= =B6nig wrote: > > > > > > > > > > Don't print a warning when we fail to allocate a page f= or swapping things out. > > > > > > > > > > > > > > > > > > > > Also rely on memalloc_nofs_save/memalloc_nofs_restore i= nstead of GFP_NOFS. > > > > > > > > > Uh this part doesn't make sense. Especially since you onl= y do it for the > > > > > > > > > debugfs file, not in general. Which means you've just com= pletely broken > > > > > > > > > the shrinker. > > > > > > > > Are you sure? My impression is that GFP_NOFS should now wor= k much more out > > > > > > > > of the box with the memalloc_nofs_save()/memalloc_nofs_rest= ore(). > > > > > > > Yeah, if you'd put it in the right place :-) > > > > > > > > > > > > > > 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 explicit gfp fl= ags. > > > > > > My impression is just the other way around. You should try to a= void 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: > > > > > > > > * %GFP_NOFS will use direct reclaim but will not use any filesyste= m > > > > interfaces. > > > > * Please try to avoid using this flag directly and instead use > > > > * memalloc_nofs_{save,restore} to mark the whole scope which > > > > cannot/shouldn't > > > > * recurse into the FS layer with a short explanation why. All allo= cation > > > > * 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 layer (ne= eds > > > GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO I thin= k). > > > > > > Adding them, maybe I got confused. > > > > My impression is that the scoped API is preferred these days. > > > > https://www.kernel.org/doc/html/latest/core-api/gfp_mask-from-fs-io.htm= l > > > > I'd probably need to spend a few months learning the DRM subsystem to > > have a more detailed opinion on whether passing GFP flags around explic= itly > > 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.koenig@am= d.com/ > and there are two things standing out. Why does ttm_tt_debugfs_shrink_sho= w > 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. 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. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch