linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Thomas Hellström (Intel)" <thomas_os@shipmail.org>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"jgg@nvidia.com" <jgg@nvidia.com>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
Date: Wed, 24 Mar 2021 11:05:40 +0100	[thread overview]
Message-ID: <a1fa7fa2-914b-366d-9902-e5b784e8428c@shipmail.org> (raw)
In-Reply-To: <YFsNRIUYrwVQanVF@phenom.ffwll.local>


On 3/24/21 10:58 AM, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
>> On 3/23/21 8:52 PM, Williams, Dan J wrote:
>>> On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (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
>>>> 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 least
>>> 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.stgit@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 until
>> 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 least
> it would all look rather pretty in the end.

Yes, I agree. Seems like the special (SW1) is available also for huge 
page table entries on x86 AFAICT, although just not implemented. 
Otherwise the SW bits appear completely used up.

The PTE size vmf_insert_pfn__xxx functions either insert one of devmap 
or special.  I think the only users of the huge insert functions apart 
form TTM currently insert devmap so we should probably be able to do the 
same, and then DRM / TTM wouldn't need to care at all about special or not.

/Thomas



> -Daniel


  reply	other threads:[~2021-03-24 10:05 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 18:45 [RFC PATCH 0/2] mm,drm/ttm: Always block GUP to TTM pages Thomas Hellström (Intel)
2021-03-21 18:45 ` [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages Thomas Hellström (Intel)
2021-03-23 11:34   ` Daniel Vetter
2021-03-23 16:34     ` Thomas Hellström (Intel)
2021-03-23 16:37       ` Jason Gunthorpe
2021-03-23 16:59         ` Christoph Hellwig
2021-03-23 17:06         ` Thomas Hellström (Intel)
2021-03-24  9:56           ` Daniel Vetter
2021-03-24 12:24             ` Jason Gunthorpe
2021-03-24 12:35               ` Thomas Hellström (Intel)
2021-03-24 12:41                 ` Jason Gunthorpe
2021-03-24 13:35                   ` Thomas Hellström (Intel)
2021-03-24 13:48                     ` Jason Gunthorpe
2021-03-24 15:50                       ` Thomas Hellström (Intel)
2021-03-24 16:38                         ` Jason Gunthorpe
2021-03-24 18:31                           ` Christian König
2021-03-24 20:07                             ` Thomas Hellström (Intel)
2021-03-24 23:14                               ` Jason Gunthorpe
2021-03-25  7:48                                 ` Thomas Hellström (Intel)
2021-03-25  8:27                                   ` Christian König
2021-03-25  9:51                                     ` Thomas Hellström (Intel)
2021-03-25 11:30                                       ` Jason Gunthorpe
2021-03-25 11:53                                         ` Thomas Hellström (Intel)
2021-03-25 12:01                                           ` Jason Gunthorpe
2021-03-25 12:09                                             ` Christian König
2021-03-25 12:36                                               ` Thomas Hellström (Intel)
2021-03-25 13:02                                                 ` Christian König
2021-03-25 13:31                                                   ` Thomas Hellström (Intel)
2021-03-25 12:42                                               ` Jason Gunthorpe
2021-03-25 13:05                                                 ` Christian König
2021-03-25 13:17                                                   ` Jason Gunthorpe
2021-03-25 13:26                                                     ` Christian König
2021-03-25 13:33                                                       ` Jason Gunthorpe
2021-03-25 13:54                                                         ` Christian König
2021-03-25 13:56                                                           ` Jason Gunthorpe
2021-03-25  7:49                                 ` Christian König
2021-03-25  9:41                                   ` Daniel Vetter
2021-03-23 13:52   ` Jason Gunthorpe
2021-03-23 15:05     ` Thomas Hellström (Intel)
2021-03-23 19:52   ` Williams, Dan J
2021-03-23 20:42     ` Thomas Hellström (Intel)
2021-03-24  9:58       ` Daniel Vetter
2021-03-24 10:05         ` Thomas Hellström (Intel) [this message]
     [not found]           ` <75423f64-adef-a2c4-8e7d-2cb814127b18@intel.com>
2021-03-24 20:22             ` Thomas Hellström (Intel)
2021-03-24 20:25               ` Dave Hansen
2021-03-25 17:51                 ` Thomas Hellström (Intel)
2021-03-25 17:55                   ` Jason Gunthorpe
2021-03-25 18:13                     ` Thomas Hellström (Intel)
2021-03-25 18:24                       ` Jason Gunthorpe
2021-03-25 18:42                         ` Thomas Hellström (Intel)
2021-03-26  9:08                         ` Thomas Hellström (Intel)
2021-03-26 11:46                           ` Jason Gunthorpe
2021-03-26 12:33                             ` Thomas Hellström (Intel)
2021-03-21 18:45 ` [RFC PATCH 2/2] mm,drm/ttm: Use VM_PFNMAP for TTM vmas Thomas Hellström (Intel)
2021-03-22  7:47   ` Christian König
2021-03-22  8:13     ` Thomas Hellström (Intel)
2021-03-23 11:57       ` Christian König
2021-03-23 11:47   ` Daniel Vetter
2021-03-23 14:04     ` Jason Gunthorpe
2021-03-23 15:51       ` Thomas Hellström (Intel)
2021-03-23 14:00   ` Jason Gunthorpe
2021-03-23 15:46     ` Thomas Hellström (Intel)
2021-03-23 16:06       ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1fa7fa2-914b-366d-9902-e5b784e8428c@shipmail.org \
    --to=thomas_os@shipmail.org \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --subject='Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox