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=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 C7040C433E0 for ; Mon, 22 Mar 2021 19:34:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4071D6199F for ; Mon, 22 Mar 2021 19:34:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4071D6199F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6E2696B00E4; Mon, 22 Mar 2021 15:34:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 691246B00E6; Mon, 22 Mar 2021 15:34:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 496C36B00E8; Mon, 22 Mar 2021 15:34:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 2766D6B00E4 for ; Mon, 22 Mar 2021 15:34:33 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D513A5841 for ; Mon, 22 Mar 2021 19:34:32 +0000 (UTC) X-FDA: 77948511984.15.0E1D188 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 53DB1E016177 for ; Mon, 22 Mar 2021 19:34:29 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id k10so23229178ejg.0 for ; Mon, 22 Mar 2021 12:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=49ZEvWwXnmSfiA1W6dXkvZ1CKfU/VlsXQJL1hS095NU=; b=e62q74y9ySftYuA0+bu5CxFIj/DjOfU243PXAPOAQJJfbQbz7Mt9FYCph35MwRKSuY 3idOJnICseyaJOsgEHPeVuNh47IhHW94trtcWbqrtDQ6BrLsjawgg3OO/6U6GNY0T7Ti 6XrBDzN6WUJyazdGYL1CBx7jMHT26920FE9CZKSfmH6jqflRzWDZkUVLn3AygenRUR3l 4HsZEepJAFqniVPx6oJY7CqzUYODyyK2EVC6oEBma+foX3cGlrP+yBV1gjYOHDi+J5j6 jKJ/Co/av/bCvGf7yyJXRgO71aQx6Hc7nCblJpVhWPTQX60d445Okn58t8KDoxXcJeIM d8Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=49ZEvWwXnmSfiA1W6dXkvZ1CKfU/VlsXQJL1hS095NU=; b=nYz+m/XUDkMC+vVu130tcAG1diX/Wptv0DHzI/S8W1zCRupJplyGMZNe08fqzUeBy0 10B6/CVmS0XfpLwAx+bA4/EDTBGJqnDUDpJlObDM4faBc3thh6Rqp0htvY0IaK/mzj7d 9K5SZaYWqVUS+Kt1SoOR6alOC0J5DqeU7JBV8CICKJN78tTytkk/lDMwefFSIbSzs04l M5/BQrRWA67fb61fuiBGJvMg2tCMWYM86M9ei/KEOdYUk4ykkewUN/TBZa539MUyDK+8 Vp416yxw05RzB4/yvBiG0pdEQapK5Uw3pz1OTQJR6iOcnXGpMWSB6Lpj9C5hDFnVJu+R gblg== X-Gm-Message-State: AOAM530b8KrrYX5x+7rn5TPz0ZWFP0COQeR1brJoBQ4We55x3XqcplaW goUoOQIW+AmCZVR25EZD0wI= X-Google-Smtp-Source: ABdhPJz59vlYSkZeN4Kue/JVfmIAZwy4VmpUwuYdoHI3gNdCHCATjRhzS2QzDLgBrhZvlM9PinE0ZA== X-Received: by 2002:a17:906:3395:: with SMTP id v21mr1378318eja.322.1616441667552; Mon, 22 Mar 2021 12:34:27 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:e345:6f8e:fa4b:2c52? ([2a02:908:1252:fb60:e345:6f8e:fa4b:2c52]) by smtp.gmail.com with ESMTPSA id v24sm10120181ejw.17.2021.03.22.12.34.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 12:34:27 -0700 (PDT) Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure To: Daniel Vetter , Michal Hocko Cc: Matthew Wilcox , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu 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> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Mon, 22 Mar 2021 20:34:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 53DB1E016177 X-Stat-Signature: 7j4zt5tyoz7bejrxp8uzfqd1659x6u8p Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mail-ej1-f53.google.com; client-ip=209.85.218.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616441669-21214 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: 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=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=B6nig w= rote: >>>>>>>>> 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 for swa= pping things out. >>>>>>>>>>> >>>>>>>>>>> Also rely on memalloc_nofs_save/memalloc_nofs_restore 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 complete= ly broken >>>>>>>>>> the shrinker. >>>>>>>>> Are you sure? My impression is that GFP_NOFS should now work mu= ch more out >>>>>>>>> of the box with the memalloc_nofs_save()/memalloc_nofs_restore(= ). >>>>>>>> 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 wh= ere you >>>>>>>> know what you're doing, you really should use explicit gfp flags= . >>>>>>> My impression is just the other way around. You should try to avo= id 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 filesyst= em >>>>> 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 all= ocation >>>>> * requests will inherit GFP_NOFS implicitly. >>>> Huh that's interesting, since iirc Willy or Dave told me the opposit= e, and >>>> the memalloc_no* stuff is for e.g. nfs calling into network layer (n= eeds >>>> GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO I thi= nk). >>>> >>>> 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.h= tml >>> >>> 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 expl= icitly >>> 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= @amd.com/ >> and there are two things standing out. Why does ttm_tt_debugfs_shrink_= 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. > 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. To summarize the debugfs code is basically to test if that stuff really=20 works with GFP_NOFS. My only concern is that if I could rely on memalloc_no* being used we=20 could optimize this quite a bit further. Regards, Christian. > -Daniel