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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_RED, USER_AGENT_SANE_1 autolearn=ham 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 976B6C433C1 for ; Tue, 23 Mar 2021 16:35:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A155619B4 for ; Tue, 23 Mar 2021 16:35:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A155619B4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF2876B00DE; Tue, 23 Mar 2021 12:35:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA2C96B00E1; Tue, 23 Mar 2021 12:35:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96A0C6B00E2; Tue, 23 Mar 2021 12:35:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 7BB1E6B00DE for ; Tue, 23 Mar 2021 12:35:04 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 320E4824999B for ; Tue, 23 Mar 2021 16:35:04 +0000 (UTC) X-FDA: 77951688528.26.5A01599 Received: from ste-pvt-msa2.bahnhof.se (ste-pvt-msa2.bahnhof.se [213.80.101.71]) by imf02.hostedemail.com (Postfix) with ESMTP id 9981140B8CC4 for ; Tue, 23 Mar 2021 16:35:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id AF9363FD99; Tue, 23 Mar 2021 17:34:57 +0100 (CET) Authentication-Results: ste-pvt-msa2.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=dWhU36oH; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Authentication-Results: ste-ftg-msa2.bahnhof.se (amavisd-new); dkim=pass (1024-bit key) header.d=shipmail.org Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IherXCBi9lB; Tue, 23 Mar 2021 17:34:56 +0100 (CET) Received: by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id B899F3FD1E; Tue, 23 Mar 2021 17:34:54 +0100 (CET) Received: from [192.168.0.209] (unknown [192.198.151.43]) by mail1.shipmail.org (Postfix) with ESMTPSA id B711336062E; Tue, 23 Mar 2021 17:34:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1616517294; bh=gIwnz5YrpsvMLr1ZSuPnF+kvE+yWmQ+lrSIsK/yX9/I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dWhU36oHnZbX8U7bf7qWiXkbbDKceZ/x7UyGk/7i1aBzR0TvA9LH9lzV6kmq4XyQB wORqOco+jomxT/WEyvcBbXxqkpKtCF3gresSz/G8v8tlnZOC2JStyhn9LU9EPMB97v ISBy4xgjnQESYi2ph174xiD/L9m3ADfw4ZwHb+AI= Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages To: dri-devel@lists.freedesktop.org, Christian Koenig , David Airlie , Andrew Morton , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210321184529.59006-1-thomas_os@shipmail.org> <20210321184529.59006-2-thomas_os@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <314fc020-d243-dbf0-acb3-ecfcc9c2443c@shipmail.org> Date: Tue, 23 Mar 2021 17:34:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Stat-Signature: i1df6hac8putaxf5ogc76mok7bkqobou X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 9981140B8CC4 Received-SPF: none (shipmail.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=ste-pvt-msa2.bahnhof.se; client-ip=213.80.101.71 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616517300-595104 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: Hi, On 3/23/21 12:34 PM, Daniel Vetter wrote: > On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellstr=C3=B6m (Intel)= wrote: >> TTM sets up huge page-table-entries both to system- and device memory, >> and we don't want gup to assume there are always valid backing struct >> pages for these. For PTEs this is handled by setting the pte_special b= it, >> but for the huge PUDs and PMDs, we have neither pmd_special nor >> pud_special. Normally, huge TTM entries are identified by looking at >> vma_is_special_huge(), but fast gup can't do that, so as an alternativ= e >> define _devmap entries for which there are no backing dev_pagemap as >> special, update documentation and make huge TTM entries _devmap, after >> verifying that there is no backing dev_pagemap. >> >> One other alternative would be to block TTM huge page-table-entries >> completely, and while currently only vmwgfx use them, they would be >> beneficial to other graphis drivers moving forward as well. >> >> Cc: Christian Koenig >> Cc: David Airlie >> Cc: Daniel Vetter >> Cc: Andrew Morton >> Cc: Jason Gunthorpe >> Cc: linux-mm@kvack.org >> Cc: dri-devel@lists.freedesktop.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Thomas Hellstr=C3=B6m (Intel) >> --- >> drivers/gpu/drm/ttm/ttm_bo_vm.c | 17 ++++++++++++++++- >> mm/gup.c | 21 +++++++++++---------- >> mm/memremap.c | 5 +++++ >> 3 files changed, 32 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm= _bo_vm.c >> index 6dc96cf66744..1c34983480e5 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c >> @@ -195,6 +195,7 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_= fault *vmf, >> pfn_t pfnt; >> struct ttm_tt *ttm =3D bo->ttm; >> bool write =3D vmf->flags & FAULT_FLAG_WRITE; >> + struct dev_pagemap *pagemap; >> =20 >> /* Fault should not cross bo boundary. */ >> page_offset &=3D ~(fault_page_size - 1); >> @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm= _fault *vmf, >> if ((pfn & (fault_page_size - 1)) !=3D 0) >> goto out_fallback; >> =20 >> + /* >> + * Huge entries must be special, that is marking them as devmap >> + * with no backing device map range. If there is a backing >> + * range, Don't insert a huge entry. >> + * If this check turns out to be too much of a performance hit, >> + * we can instead have drivers indicate whether they may have >> + * backing device map ranges and if not, skip this lookup. >> + */ > I think we can do this statically: > - if it's system memory we know there's no devmap for it, and we do the > trick to block gup_fast Yes, that should work. > - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV= , > so might as well not do that I think gup_fast will unfortunately mistake a huge iomem page for an=20 ordinary page and try to access a non-existant struct page for it,=20 unless we do the devmap trick. And the lookup would then be for the rare case where a driver would have=20 already registered a dev_pagemap for an iomem area which may also be=20 mapped through TTM (like the patch from Felix a couple of weeks ago). If=20 a driver can promise not to do that, then we can safely remove the lookup= . /Thomas