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 651A4C433E0 for ; Tue, 23 Mar 2021 13:15:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6412D61984 for ; Tue, 23 Mar 2021 13:15:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6412D61984 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 D0CD38D000B; Tue, 23 Mar 2021 09:15:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE45F8D0001; Tue, 23 Mar 2021 09:15:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAC738D000B; Tue, 23 Mar 2021 09:15:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0109.hostedemail.com [216.40.44.109]) by kanga.kvack.org (Postfix) with ESMTP id A00748D0001 for ; Tue, 23 Mar 2021 09:15:10 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 68BB73A97 for ; Tue, 23 Mar 2021 13:15:10 +0000 (UTC) X-FDA: 77951184780.14.A58E657 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf07.hostedemail.com (Postfix) with ESMTP id A151EA0009E8 for ; Tue, 23 Mar 2021 13:15:08 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id e9so20728443wrw.10 for ; Tue, 23 Mar 2021 06:15:08 -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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=aqwQ8INpvvw/8hSSkL2yFRZQ/5FKsb6N4k2DX49lCIQ7IkwfhQ7opbL1FYgSNm4a8B S7YvGusAzEdOzzRp3SmT8OZOlMWx4SL/1wVo3TtykDDS++Hlrjq1Mx0aaJAvVL9RDLM9 kLL/vnRw36iDcw7oNf1ZsIY0Bso+i0dOBhhtE= 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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=U/SXZXFGFe5kEcRdx5le07/WPXoOhOLVc+bYDa+bUlXqtOhhw2BrJX+YUnRkxgp7af JA2wIMyE2q1lazsFoH9hrB7T2jVm5iuU/24AmCis1QC3ZH6g6sf48XYVI/KnACpDXwPJ HbCHGuyTqlE4UxiI8XziQ9FoVCKTSZmIDFmOksyysmt7uqR+7zHDXqaG074N996ft/A2 EmvGI/3sg3h4o6HyuzaT3OzIuVlElxiBsajCrjusASe5Vj9UTTRmQ1AtZaOx+4JD4lvF DnPjJhoBpLotOC63Ao8ZY+hoEZGAtiGy+TXIUNHm0X1VwnG9Li0safTwSDLtktzNUmlz pCLg== X-Gm-Message-State: AOAM533dB0N9pNzrXNaS6Y+8IheudbB7nTB16ASMb4vp9aEzE0whRh8V no/ahrZxVdkLIC6BBJf+5AKdkQ== X-Google-Smtp-Source: ABdhPJywDfPOd6wXKDUxUiwLpU18IcUiEdVHqY4oHohRVLm0NQywzWa+WVQFgaVsa9S9fs5+ie+RYQ== X-Received: by 2002:adf:ec46:: with SMTP id w6mr3894009wrn.213.1616505307255; Tue, 23 Mar 2021 06:15:07 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id s83sm2704385wms.16.2021.03.23.06.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 06:15:06 -0700 (PDT) Date: Tue, 23 Mar 2021 14:15:05 +0100 From: Daniel Vetter To: Michal Hocko Cc: Christian =?iso-8859-1?Q?K=F6nig?= , Matthew Wilcox , amd-gfx list , Linux MM , dri-devel , 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 , amd-gfx list , Linux MM , dri-devel , Dave Chinner , Leo Liu References: <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: rspam04 X-Rspamd-Queue-Id: A151EA0009E8 X-Stat-Signature: k7gffdc4pd8857qj8uz1ornyamznos6a Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf07; identity=mailfrom; envelope-from=""; helo=mail-wr1-f52.google.com; client-ip=209.85.221.52 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616505308-488423 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 01:04:03PM +0100, Michal Hocko wrote: > On Tue 23-03-21 12:48:58, Christian K=F6nig wrote: > > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > > 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 bug= s are > > > > pretty much guaranteed. So whether we use explicit gfp flags or t= he > > > > context apis, result is exactly the same. > >=20 > > Ok let us recap what TTMs TT shrinker does here: > >=20 > > 1. We got memory which is not swapable because it might be accessed b= y the > > GPU at any time. > > 2. Make sure the memory is not accessed by the GPU and driver need to= grab a > > lock before they can make it accessible again. > > 3. Allocate a shmem file and copy over the not swapable pages. >=20 > This is quite tricky because the shrinker operates in the PF_MEMALLOC > context so such an allocation would be allowed to completely deplete > memory unless you explicitly mark that context as __GFP_NOMEMALLOC. Als= o > note that if the allocation cannot succeed it will not trigger reclaim > again because you are already called from the reclaim context. [Limiting to that discussion] Yes it's not emulating real (direct) reclaim correctly, but ime the biggest issue with direct reclaim is when you do mutex_lock instead of mutex_trylock or in general block on stuff that you cant. And lockdep + fs_reclaim annotations gets us that, so pretty good to make sure our shrinker is correct. Actual tuning of it and making sure it's not doing silly things is ofc a different thing, and for that we can't test it in isolation. But it's goo= d to know that before you tune it, you have rather high confidence it's at least correct. And for that not running with PF_MEMALLOC is actually good, since it means more allocation failures, so more testing of those error/backoff paths in the code. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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 6FD1EC433DB for ; Tue, 23 Mar 2021 13:15:10 +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 0CA5161878 for ; Tue, 23 Mar 2021 13:15:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CA5161878 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 638B46E857; Tue, 23 Mar 2021 13:15:09 +0000 (UTC) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by gabe.freedesktop.org (Postfix) with ESMTPS id B73776E8F7 for ; Tue, 23 Mar 2021 13:15:08 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id v11so20714565wro.7 for ; Tue, 23 Mar 2021 06:15:08 -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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=aqwQ8INpvvw/8hSSkL2yFRZQ/5FKsb6N4k2DX49lCIQ7IkwfhQ7opbL1FYgSNm4a8B S7YvGusAzEdOzzRp3SmT8OZOlMWx4SL/1wVo3TtykDDS++Hlrjq1Mx0aaJAvVL9RDLM9 kLL/vnRw36iDcw7oNf1ZsIY0Bso+i0dOBhhtE= 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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=q3t5ouwmmrmZMBHTbSKqA7jMAaUevpyGv5g6eF/or5i3xmAbwFkdtbuo3+pZ6MLhnd zPLpcNjL8I5FdrVdkQ0xO544oKEvDSyrDiqt3dE7WGtbvAx54Gf1a+gufCpNDuUhNqOm X/bysUPgVA+SCouZcO79NwE7A6103VTDjztmKSpW/BtNq279oRDe9P7epQZOR5bJkR+e guu0UAznUMd5ghB+Jb7uc7mEBWlCWYRmSWSlf90xHE0xQCX22l8oNWgIpIBkW/ME9boA BH0K9kQt25gsvE7BLsr6K7WqYNsls/UTe2dY1Bv9+hvREFCACCdul/BsjAemnM+mouvi Jt5w== X-Gm-Message-State: AOAM533aV881SlgXDr/k2Bih1GxwQdMhhm4zMzqZkQd33L054BtA+T5r 98CNx9QU8eyBwVSxCtSsetyuiA== X-Google-Smtp-Source: ABdhPJywDfPOd6wXKDUxUiwLpU18IcUiEdVHqY4oHohRVLm0NQywzWa+WVQFgaVsa9S9fs5+ie+RYQ== X-Received: by 2002:adf:ec46:: with SMTP id w6mr3894009wrn.213.1616505307255; Tue, 23 Mar 2021 06:15:07 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id s83sm2704385wms.16.2021.03.23.06.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 06:15:06 -0700 (PDT) Date: Tue, 23 Mar 2021 14:15:05 +0100 From: Daniel Vetter To: Michal Hocko 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 , amd-gfx list , Linux MM , dri-devel , Dave Chinner , Leo Liu References: <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 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?= , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 23, 2021 at 01:04:03PM +0100, Michal Hocko wrote: > On Tue 23-03-21 12:48:58, Christian K=F6nig wrote: > > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > > 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 d= irect > > > > 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. > > = > > Ok let us recap what TTMs TT shrinker does here: > > = > > 1. We got memory which is not swapable because it might be accessed by = the > > GPU at any time. > > 2. Make sure the memory is not accessed by the GPU and driver need to g= rab a > > lock before they can make it accessible again. > > 3. Allocate a shmem file and copy over the not swapable pages. > = > This is quite tricky because the shrinker operates in the PF_MEMALLOC > context so such an allocation would be allowed to completely deplete > memory unless you explicitly mark that context as __GFP_NOMEMALLOC. Also > note that if the allocation cannot succeed it will not trigger reclaim > again because you are already called from the reclaim context. [Limiting to that discussion] Yes it's not emulating real (direct) reclaim correctly, but ime the biggest issue with direct reclaim is when you do mutex_lock instead of mutex_trylock or in general block on stuff that you cant. And lockdep + fs_reclaim annotations gets us that, so pretty good to make sure our shrinker is correct. Actual tuning of it and making sure it's not doing silly things is ofc a different thing, and for that we can't test it in isolation. But it's good to know that before you tune it, you have rather high confidence it's at least correct. And for that not running with PF_MEMALLOC is actually good, since it means more allocation failures, so more testing of those error/backoff paths in the code. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ 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 EBB23C433DB for ; Tue, 23 Mar 2021 13:15:14 +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 76FDF61990 for ; Tue, 23 Mar 2021 13:15:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76FDF61990 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 7D77E6E8F7; Tue, 23 Mar 2021 13:15:10 +0000 (UTC) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by gabe.freedesktop.org (Postfix) with ESMTPS id A80E06E857 for ; Tue, 23 Mar 2021 13:15:08 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id j7so20747136wrd.1 for ; Tue, 23 Mar 2021 06:15:08 -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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=aqwQ8INpvvw/8hSSkL2yFRZQ/5FKsb6N4k2DX49lCIQ7IkwfhQ7opbL1FYgSNm4a8B S7YvGusAzEdOzzRp3SmT8OZOlMWx4SL/1wVo3TtykDDS++Hlrjq1Mx0aaJAvVL9RDLM9 kLL/vnRw36iDcw7oNf1ZsIY0Bso+i0dOBhhtE= 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=8lz3lDk13H1M2ymaJV1txo9yAd3G66LPnXWxpBCwGC8=; b=o58XFHIhcAmd5VCakCf3ZbXzrXrXPIwoOq2ykCQpfZ2eAFPaJCUdNoyeSfd+wkwdxq +RLMyx7Pq2/Y+cuTv0xJjMb4+IaEuZ8QAeMDbfily7JLoU2S2kW32NKlxOCZQkUTMtIS 9ZGRqF8clAQ5mfW6nCRiU+UQVOEAX+R1A1PupTHpj/Mj3CfyEEuxqgj/yoGN6tJWTGws YoLscXTvYeJgsTBB3Mp1vDno4GynBox32qLHVFvAkGdUbJmmyrwlPEnM4KpOd189WXx5 vFJ3uf5zC8l7QbCpgNtI50mPyeifQGdXp2jZV1WZZlTrrMQGWe0H5KZbWT+RQ+8dJ6RW KIfw== X-Gm-Message-State: AOAM530QIl+rPBkHD7CpTdE+V3cgyH8y71GuGgE3gqmqPM25yigSs8aA egOL9bMqpPbCo52gAA5fE+ur9Q== X-Google-Smtp-Source: ABdhPJywDfPOd6wXKDUxUiwLpU18IcUiEdVHqY4oHohRVLm0NQywzWa+WVQFgaVsa9S9fs5+ie+RYQ== X-Received: by 2002:adf:ec46:: with SMTP id w6mr3894009wrn.213.1616505307255; Tue, 23 Mar 2021 06:15:07 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id s83sm2704385wms.16.2021.03.23.06.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 06:15:06 -0700 (PDT) Date: Tue, 23 Mar 2021 14:15:05 +0100 From: Daniel Vetter To: Michal Hocko 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 , amd-gfx list , Linux MM , dri-devel , Dave Chinner , Leo Liu References: <20210322140548.GN1719932@casper.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 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?= , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Tue, Mar 23, 2021 at 01:04:03PM +0100, Michal Hocko wrote: > On Tue 23-03-21 12:48:58, Christian K=F6nig wrote: > > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > > 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 d= irect > > > > 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. > > = > > Ok let us recap what TTMs TT shrinker does here: > > = > > 1. We got memory which is not swapable because it might be accessed by = the > > GPU at any time. > > 2. Make sure the memory is not accessed by the GPU and driver need to g= rab a > > lock before they can make it accessible again. > > 3. Allocate a shmem file and copy over the not swapable pages. > = > This is quite tricky because the shrinker operates in the PF_MEMALLOC > context so such an allocation would be allowed to completely deplete > memory unless you explicitly mark that context as __GFP_NOMEMALLOC. Also > note that if the allocation cannot succeed it will not trigger reclaim > again because you are already called from the reclaim context. [Limiting to that discussion] Yes it's not emulating real (direct) reclaim correctly, but ime the biggest issue with direct reclaim is when you do mutex_lock instead of mutex_trylock or in general block on stuff that you cant. And lockdep + fs_reclaim annotations gets us that, so pretty good to make sure our shrinker is correct. Actual tuning of it and making sure it's not doing silly things is ofc a different thing, and for that we can't test it in isolation. But it's good to know that before you tune it, you have rather high confidence it's at least correct. And for that not running with PF_MEMALLOC is actually good, since it means more allocation failures, so more testing of those error/backoff paths in the code. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx