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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 A9A73C433C1 for ; Wed, 24 Mar 2021 10:05:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3CBE6619FF for ; Wed, 24 Mar 2021 10:05:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CBE6619FF 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 A9C386B027E; Wed, 24 Mar 2021 06:05:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4B776B02A9; Wed, 24 Mar 2021 06:05:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89E7F6B02AA; Wed, 24 Mar 2021 06:05:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 673F56B027E for ; Wed, 24 Mar 2021 06:05:48 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1AF2B8249980 for ; Wed, 24 Mar 2021 10:05:48 +0000 (UTC) X-FDA: 77954336376.34.D5D5675 Received: from ste-pvt-msa1.bahnhof.se (ste-pvt-msa1.bahnhof.se [213.80.101.70]) by imf30.hostedemail.com (Postfix) with ESMTP id D6601E0011CE for ; Wed, 24 Mar 2021 10:05:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id EFF9F3F3B2; Wed, 24 Mar 2021 11:05:44 +0100 (CET) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=R6CVz1lG; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBylAn-1dOM1; Wed, 24 Mar 2021 11:05:43 +0100 (CET) Received: by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 7CBCD3F496; Wed, 24 Mar 2021 11:05:42 +0100 (CET) Received: from [192.168.0.209] (unknown [192.198.151.43]) by mail1.shipmail.org (Postfix) with ESMTPSA id 1AA393605CC; Wed, 24 Mar 2021 11:05:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1616580342; bh=buvsm/mpmVDWeMogh3TWH4oG8ngAhMEnBYvFmnLpFqA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=R6CVz1lGUwvmcBG5/P7NEW33eeLoNMuVheHxOWPjYptl1W8DUEHMFsmkyCF/3TIEC fbNDH7kQbxC/sOuzyj5g4HaZj5x+iNL3UQ6SW/p3hVGJEdBQR0PTpWiUpfFWqf1M/U 6L3EXD8z4yyoOuweLsLQfulwKE5AijpvaXq8RqYg= Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages To: "Williams, Dan J" , "dri-devel@lists.freedesktop.org" , "christian.koenig@amd.com" , "jgg@nvidia.com" , "airlied@linux.ie" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.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: Date: Wed, 24 Mar 2021 11:05:40 +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: jkzjaonu3z9oboy3j31h6nmymi46sww3 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D6601E0011CE Received-SPF: none (shipmail.org>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=ste-pvt-msa1.bahnhof.se; client-ip=213.80.101.70 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616580344-958992 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 3/24/21 10:58 AM, Daniel Vetter wrote: > On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellstr=C3=B6m (Intel)= wrote: >> On 3/23/21 8:52 PM, Williams, Dan J wrote: >>> On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellstr=C3=B6m (Intel) wrot= e: >>>> 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 struc= t >>>> pages for these. For PTEs this is handled by setting the pte_special >>>> bit, >>>> 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 >>>> alternative >>>> 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. >>> Please do not abuse p{m,u}d_devmap like this. I'm in the process of >>> removing get_devpagemap() from the gup-fast path [1]. Instead there >>> should be space for p{m,u}d_special in the page table entries (at lea= st >>> for x86-64). So the fix is to remove that old assumption that huge >>> pages can never be special. >>> >>> [1]: >>> http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.stg= it@dwillia2-desk3.amr.corp.intel.com >>> >> Hmm, yes with that patch it will obviously not work as intended. >> >> Given that, I think we'll need to disable the TTM huge pages for now u= ntil >> we can sort out and agree on using a page table entry bit. > Yeah :-/ > > I think going full pud/pmd_mkspecial should then also mesh well with > Jason's request to wrap it all up into a vmf_insert_* helper, so at lea= st > it would all look rather pretty in the end. Yes, I agree. Seems like the special (SW1) is available also for huge=20 page table entries on x86 AFAICT, although just not implemented.=20 Otherwise the SW bits appear completely used up. The PTE size vmf_insert_pfn__xxx functions either insert one of devmap=20 or special.=C2=A0 I think the only users of the huge insert functions apa= rt=20 form TTM currently insert devmap so we should probably be able to do the=20 same, and then DRM / TTM wouldn't need to care at all about special or no= t. /Thomas > -Daniel