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,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 978EFC433DB for ; Tue, 23 Mar 2021 13:06:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3D8C2619B6 for ; Tue, 23 Mar 2021 13:06:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D8C2619B6 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 B8FCE8D000C; Tue, 23 Mar 2021 09:06:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B661E8D000B; Tue, 23 Mar 2021 09:06:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A06758D000C; Tue, 23 Mar 2021 09:06:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 83FE08D000B for ; Tue, 23 Mar 2021 09:06:33 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 404AC1F10 for ; Tue, 23 Mar 2021 13:06:33 +0000 (UTC) X-FDA: 77951163066.19.EF5E4BB Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf06.hostedemail.com (Postfix) with ESMTP id 4B26DC0007EC for ; Tue, 23 Mar 2021 13:06:29 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id u5so26980048ejn.8 for ; Tue, 23 Mar 2021 06:06:29 -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=e6FkST9t2ZwpU9tBoGwmlJ/8krgDpq4Z1yoPeMffQAs=; b=JL9OLr5bDQalWKZUrxo9qn1wSQaO/JngJ0lPvSKQHewn1QW4fy5DOUla5h3IcYwDVB qph2EnAwiQnfto2zfX1xXNV+8htZV+Nf5iEZiQAc9H5e787bJj8BcMAywKm5x6/WpOYr rzjO9c3pYKFPf5ce07ZO8VsPO3nPq/+OPI2GsahzrhQSS8qZcO5gE8gFusY0WSBCIjR1 5SwDFATrNAQKYal93ya+zzErrHASFcjuomGLDpfWKyR2R07HY7jWxad9QFd5MhwXgVV4 clp0y4WdpkJaEh9RxQNgEO6mUqLzNNdmokJI5obKVacGAGJTcEXGor9spBfr+nUooAY/ 6d3Q== 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=e6FkST9t2ZwpU9tBoGwmlJ/8krgDpq4Z1yoPeMffQAs=; b=r6ORt6CkX/NOfO9+wkVMS4LYKXCgRXeb6nIESdXa8JXOLfQrO4+2XHA64hIBpfVU33 6O6Rg2tkjA3h2q3m2zO4E/nkdojSw5EGv3S+5tWc2g+f+s3QSHN5u20M2aFHGyjfDBqQ tOkw+lPPoPRy7JKN1wAbVVn5RjUjR/sge0dwxOm4yqxFnKzbz2ub5ucjBR7UOmyLf9Jm m6EzqYAfcpV/6tv1BxjAhUCTK7kWQpMIbD++jf9oMSmP1zj9BD7Wpi1q5au+oB3TR/Zv p4//oMgZYmZGwK7z6d7NJyw1C1HinXtpq39BZrbgqDmArYXuDP4vOYrMa5r0MLNgVNRQ hlxg== X-Gm-Message-State: AOAM533IKZE22etgF9hzNI7ENk1ZzsKpDw2O2w8WMKa+xmv1j41yJzX+ IyFnLQNK8MYi7Rm7BYx9+UY= X-Google-Smtp-Source: ABdhPJyd4BvrBuru1/OFtDtS9Lx0wcR+CT3lNk6Rtk/k81vnYY04OLJgnIZ0sLUdHJ+Noiq4GteXbw== X-Received: by 2002:a17:906:1d4e:: with SMTP id o14mr4731609ejh.549.1616504788155; Tue, 23 Mar 2021 06:06:28 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:fdcd:4dd1:a1af:a7ec? ([2a02:908:1252:fb60:fdcd:4dd1:a1af:a7ec]) by smtp.gmail.com with ESMTPSA id i2sm12687682edy.72.2021.03.23.06.06.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Mar 2021 06:06:27 -0700 (PDT) Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure To: Michal Hocko Cc: Matthew Wilcox , dri-devel , Linux MM , amd-gfx list , Dave Chinner , Leo Liu References: <20210322140548.GN1719932@casper.infradead.org> <75ff80c5-a054-d13d-85c1-0040addb45d2@gmail.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <20808d08-b66c-13c3-f672-ebce216b2fa2@gmail.com> Date: Tue, 23 Mar 2021 14:06: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-Stat-Signature: nxp9pdff8aokmajcn5t9dpcs8wjsu6r9 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4B26DC0007EC Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mail-ej1-f41.google.com; client-ip=209.85.218.41 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616504789-405622 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 23.03.21 um 13:37 schrieb Michal Hocko: > On Tue 23-03-21 13:21:32, Christian K=C3=B6nig wrote: >> Am 23.03.21 um 13:04 schrieb Michal Hocko: >>> On Tue 23-03-21 12:48:58, Christian K=C3=B6nig wrote: >>>> Am 23.03.21 um 12:28 schrieb Daniel Vetter: >>>>> On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: >>>>>> On Mon 22-03-21 20:34:25, Christian K=C3=B6nig wrote: >>> [...] >>>>>>> My only concern is that if I could rely on memalloc_no* being use= d we could >>>>>>> optimize this quite a bit further. >>>>>> Yes you can use the scope API and you will be guaranteed that _any= _ >>>>>> allocation from the enclosed context will inherit GFP_NO* semantic= . >>>> The question is if this is also guaranteed the other way around? >>>> >>>> In other words if somebody calls get_free_page(GFP_NOFS) are the con= text >>>> flags set as well? >>> gfp mask is always restricted in the page allocator. So say you have >>> noio scope context and call get_free_page/kmalloc(GFP_NOFS) then the >>> scope would restrict the allocation flags to GFP_NOIO (aka drop >>> __GFP_IO). For further details, have a look at current_gfp_context >>> and its callers. >>> >>> Does this answer your question? >> But what happens if you don't have noio scope and somebody calls >> get_free_page(GFP_NOFS)? > Then this will be a regular NOFS request. Let me repeat scope API will > further restrict any requested allocation mode. Ok, got it. > >> Is then the noio scope added automatically? And is it possible that th= e >> shrinker gets called without noio scope even we would need it? > Here you have lost me again. > >>>>>> 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 th= e >>>>>> 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 t= o grab 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. >> Thanks, exactly that was one thing I was absolutely not sure about. An= d yes >> I agree that this is really tricky. >> >> Ideally I would like to be able to trigger swapping out the shmem page= I >> allocated immediately after doing the copy. > So let me try to rephrase to make sure I understand. You would like to > swap out the existing content from the shrinker and you use shmem as a > way to achieve that. The swapout should happen at the time of copying > (shrinker context) or shortly afterwards? > > So effectively to call pageout() on the shmem page after the copy? Yes, exactly that. >> This way I would only need a single page for the whole shrink operatio= n at >> any given time. > What do you mean by that? You want the share the same shmem page for > other copy+swapout? Correct, yes. The idea is that we can swap out the content of a full GPU buffer object=20 this way to give the backing store of the object back to the core memory=20 managment. Regards, Christian.