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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_RED 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 42C4DC433DB for ; Tue, 23 Mar 2021 11:34:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 920776191F for ; Tue, 23 Mar 2021 11:34:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 920776191F 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 20BF16B0168; Tue, 23 Mar 2021 07:34:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BB726B016A; Tue, 23 Mar 2021 07:34:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 034016B016B; Tue, 23 Mar 2021 07:34:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id D60FD6B0168 for ; Tue, 23 Mar 2021 07:34:43 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8CF8F6D72 for ; Tue, 23 Mar 2021 11:34:43 +0000 (UTC) X-FDA: 77950931646.11.9A667C8 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf01.hostedemail.com (Postfix) with ESMTP id AF336500152C for ; Tue, 23 Mar 2021 11:34:42 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id a132-20020a1c668a0000b029010f141fe7c2so10585619wmc.0 for ; Tue, 23 Mar 2021 04:34:42 -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=kJG6PyZc23JI+PUGii9zTxJBB3El6qdcUXm7Ja4hn5w=; b=WH+kDMCfYBdW7/F2qQa1invWtJWWKHsmhMnK7Wa6ORo5PhDr8OH1NtstjlLVKkIYNJ zE+MVu0P11LlLzWbcm8J/yUSsIPb2gXI7FPN5EedkchW8r7aT+8ayoOl8KiNNR1p2XVk bToehT/I1pqXS+twn7B1+B76Tu0Ojh7JAtVUc= 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=kJG6PyZc23JI+PUGii9zTxJBB3El6qdcUXm7Ja4hn5w=; b=t0KeeOUBFwsEGUQUhFw7n+26sc1KKkBGUWIVogYiJjI8ehwW6V1NvtXjIisnE0sMCj sWRTdgqpAMv56tTd3svRZkYLFYXxv8YqmFgjc3vyrpGmXfX1ixpy60ZKAaP00gyvSTxf yVuqFJ3AB+5dyxsweKOliBlHbNjj8PfKdAeGGWknjaYUad0LAISkQbN9iUtkHUDKsg7A V/FHFq39fzXhkM1Y7+k7ePETapxRgWI4hdAD9nagSyGBqN9kY/9sgRP9eBmLxEHtFFVI 5jySM1fcCRce02mdnhbqDHmippps0/2WrZz7gQsoPnY9xK6kHdPesqPQX2GRMg4+Q5Oi /0ww== X-Gm-Message-State: AOAM5309O0KrYXsvg0sQbAWBij1CnZdwt4ngevTAKPX/P5H8HOc/JpdV wvFpBshb+L9OQQaG/DgBvXa8mA== X-Google-Smtp-Source: ABdhPJxIn1uOvVoXyyDbPHMe7z9nkcLsx6iPBeZVerfGAZRaAPQO90B8PHsR5Uu1okld1HMrH4DIcg== X-Received: by 2002:a1c:498b:: with SMTP id w133mr2995826wma.134.1616499281914; Tue, 23 Mar 2021 04:34:41 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id z2sm26287859wrm.0.2021.03.23.04.34.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 04:34:41 -0700 (PDT) Date: Tue, 23 Mar 2021 12:34:39 +0100 From: Daniel Vetter To: Thomas =?iso-8859-1?Q?Hellstr=F6m_=28Intel=29?= Cc: dri-devel@lists.freedesktop.org, Christian Koenig , David Airlie , Daniel Vetter , Andrew Morton , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages Message-ID: Mail-Followup-To: Thomas =?iso-8859-1?Q?Hellstr=F6m_=28Intel=29?= , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20210321184529.59006-2-thomas_os@shipmail.org> X-Operating-System: Linux phenom 5.7.0-1-amd64 X-Stat-Signature: 7bukst8wzjuk9sqtjnr79aimhrwatsf1 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AF336500152C Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-wm1-f51.google.com; client-ip=209.85.128.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616499282-789233 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 Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellstr=F6m (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 struct > pages for these. For PTEs this is handled by setting the pte_special bi= t, > 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. >=20 > 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. >=20 > 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=F6m (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(-) >=20 > 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_f= ault *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 - 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 that would cover all cases without this check here? -Daniel > + pagemap =3D get_dev_pagemap(pfn, NULL); > + if (pagemap) { > + put_dev_pagemap(pagemap); > + goto out_fallback; > + } > + > /* Check that memory is contiguous. */ > if (!bo->mem.bus.is_iomem) { > for (i =3D 1; i < fault_page_size; ++i) { > @@ -223,7 +238,7 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_f= ault *vmf, > } > } > =20 > - pfnt =3D __pfn_to_pfn_t(pfn, PFN_DEV); > + pfnt =3D __pfn_to_pfn_t(pfn, PFN_DEV | PFN_MAP); > if (fault_page_size =3D=3D (HPAGE_PMD_SIZE >> PAGE_SHIFT)) > ret =3D vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write); > #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD > diff --git a/mm/gup.c b/mm/gup.c > index e40579624f10..1b6a127f0bdd 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1993,6 +1993,17 @@ static void __maybe_unused undo_dev_pagemap(int = *nr, int nr_start, > } > =20 > #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > +/* > + * If we can't determine whether or not a pte is special, then fail im= mediately > + * for ptes. Note, we can still pin HugeTLB as it is guaranteed not to= be > + * special. For THP, special huge entries are indicated by xxx_devmap(= ) > + * returning true, but a corresponding call to get_dev_pagemap() will > + * return NULL. > + * > + * For a futex to be placed on a THP tail page, get_futex_key requires= a > + * get_user_pages_fast_only implementation that can pin pages. Thus it= 's still > + * useful to have gup_huge_pmd even if we can't operate on ptes. > + */ > static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long = end, > unsigned int flags, struct page **pages, int *nr) > { > @@ -2069,16 +2080,6 @@ static int gup_pte_range(pmd_t pmd, unsigned lon= g addr, unsigned long end, > return ret; > } > #else > - > -/* > - * If we can't determine whether or not a pte is special, then fail im= mediately > - * for ptes. Note, we can still pin HugeTLB and THP as these are guara= nteed not > - * to be special. > - * > - * For a futex to be placed on a THP tail page, get_futex_key requires= a > - * get_user_pages_fast_only implementation that can pin pages. Thus it= 's still > - * useful to have gup_huge_pmd even if we can't operate on ptes. > - */ > static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long = end, > unsigned int flags, struct page **pages, int *nr) > { > diff --git a/mm/memremap.c b/mm/memremap.c > index 7aa7d6e80ee5..757551cd2a4d 100644 > --- a/mm/memremap.c > +++ b/mm/memremap.c > @@ -471,6 +471,11 @@ void vmem_altmap_free(struct vmem_altmap *altmap, = unsigned long nr_pfns) > * > * If @pgmap is non-NULL and covers @pfn it will be returned as-is. I= f @pgmap > * is non-NULL but does not cover @pfn the reference to it will be rel= eased. > + * > + * Return: A referenced pointer to a struct dev_pagemap containing @pf= n, > + * or NULL if there was no such pagemap registered. For interpretion > + * of NULL returns for pfns extracted from valid huge page table entri= es, > + * please see gup_pte_range(). > */ > struct dev_pagemap *get_dev_pagemap(unsigned long pfn, > struct dev_pagemap *pgmap) > --=20 > 2.30.2 >=20 --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch