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 43896C433E2 for ; Tue, 23 Mar 2021 13:48:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B38956198C for ; Tue, 23 Mar 2021 13:48:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B38956198C 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 260646B00F0; Tue, 23 Mar 2021 09:48:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 210836B00F2; Tue, 23 Mar 2021 09:48:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08A976B00F3; Tue, 23 Mar 2021 09:48:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id E40C06B00F0 for ; Tue, 23 Mar 2021 09:48:08 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9E77A7593 for ; Tue, 23 Mar 2021 13:48:08 +0000 (UTC) X-FDA: 77951267856.32.39F1025 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf21.hostedemail.com (Postfix) with ESMTP id 52278E0011FC for ; Tue, 23 Mar 2021 13:48:07 +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=1616507286; 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=6tF7KSRmZ6+Q2eQmtg3qs6Lj7pxyXqSPb+EoL1Xiwgo=; b=CauOHGc6V6duECZzZ4rC2VPuL2MdIyErENX91lTCz7oUhGFaYtQ4z0Xh5Yii3ZWbnl+WLA geknr5fCNCQCICctxKfxYP27oB6cXHGwPK6ZJvQH6GTykbnPfqiqxnDn74HcLe4CwumITs RZCSbOiJvRcExSTyuUSE9rGIn5qhIas= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 43567ACBF; Tue, 23 Mar 2021 13:48:06 +0000 (UTC) Date: Tue, 23 Mar 2021 14:48:00 +0100 From: Michal Hocko To: Daniel Vetter 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: 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-Stat-Signature: gmktsh7hik6db7z4h8b71c7s7ofmc9g6 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 52278E0011FC Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616507287-271456 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 23-03-21 14:15:05, Daniel Vetter wrote: > 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 d= o: We > > > > > really shouldn't do different tricks and calling contexts betwe= en direct > > > > > reclaim and kswapd reclaim. Otherwise very hard to track down b= ugs are > > > > > pretty much guaranteed. So whether we use explicit gfp flags or= the > > > > > 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= by 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. A= lso > > note that if the allocation cannot succeed it will not trigger reclai= m > > again because you are already called from the reclaim context. >=20 > [Limiting to that discussion] >=20 > 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. I have to confess that I manage to (happily) forget all the nasty details about fs_reclaim lockdep internals so I am not sure the use by the proposed patch is actually reasonable. Talk to lockdep guys about that and make sure to put a big fat comment explaining what is going on. In general allocating from the reclaim context is a bad idea and you should avoid that. As already said a simple allocation request from the reclaim context is not constrained and it will not recurse back into the reclaim. Calling into shmem from the shrinker context might be really tricky as well. I am not even sure this is possible for anything other than full (GFP_KERNEL) reclaim context. --=20 Michal Hocko SUSE Labs