From: "Thomas Hellström (Intel)" <thomas_os@shipmail.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"Matthew Wilcox" <willy@infradead.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"John Stultz" <john.stultz@linaro.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Christian König" <christian.koenig@amd.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Date: Mon, 1 Mar 2021 09:39:53 +0100 [thread overview]
Message-ID: <b367b7e8-f202-4d23-d672-a5c9bc7fcec1@shipmail.org> (raw)
In-Reply-To: <CAKMK7uE=8+hj-MUFXHFoG_hAbz_Obi8a99+DE5_d1K+KZaG+tQ@mail.gmail.com>
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
> On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
> <thomas_os@shipmail.org> wrote:
>> On 2/26/21 2:28 PM, Daniel Vetter wrote:
>>> So I think it stops gup. But I haven't verified at all. Would be good
>>> if Christian can check this with some direct io to a buffer in system
>>> memory.
>> Hmm,
>>
>> Docs (again vm_normal_page() say)
>>
>> * VM_MIXEDMAP mappings can likewise contain memory with or without "struct
>> * page" backing, however the difference is that _all_ pages with a struct
>> * page (that is, those where pfn_valid is true) are refcounted and
>> considered
>> * normal pages by the VM. The disadvantage is that pages are refcounted
>> * (which can be slower and simply not an option for some PFNMAP
>> users). The
>> * advantage is that we don't have to follow the strict linearity rule of
>> * PFNMAP mappings in order to support COWable mappings.
>>
>> but it's true __vm_insert_mixed() ends up in the insert_pfn() path, so
>> the above isn't really true, which makes me wonder if and in that case
>> why there could any longer ever be a significant performance difference
>> between MIXEDMAP and PFNMAP.
> Yeah it's definitely confusing. I guess I'll hack up a patch and see
> what sticks.
>
>> BTW regarding the TTM hugeptes, I don't think we ever landed that devmap
>> hack, so they are (for the non-gup case) relying on
>> vma_is_special_huge(). For the gup case, I think the bug is still there.
> Maybe there's another devmap hack, but the ttm_vm_insert functions do
> use PFN_DEV and all that. And I think that stops gup_fast from trying
> to find the underlying page.
> -Daniel
Hmm perhaps it might, but I don't think so. The fix I tried out was to set
PFN_DEV | PFN_MAP for huge PTEs which causes pfn_devmap() to be true,
and then
follow_devmap_pmd()->get_dev_pagemap() which returns NULL and gup_fast()
backs off,
in the end that would mean setting in stone that "if there is a huge
devmap page table entry for which we haven't registered any devmap
struct pages (get_dev_pagemap returns NULL), we should treat that as a
"special" huge page table entry".
From what I can tell, all code calling get_dev_pagemap() already does
that, it's just a question of getting it accepted and formalizing it.
/Thomas
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström (Intel)" <thomas_os@shipmail.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"Matthew Wilcox" <willy@infradead.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Christian König" <christian.koenig@amd.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Date: Mon, 1 Mar 2021 09:39:53 +0100 [thread overview]
Message-ID: <b367b7e8-f202-4d23-d672-a5c9bc7fcec1@shipmail.org> (raw)
In-Reply-To: <CAKMK7uE=8+hj-MUFXHFoG_hAbz_Obi8a99+DE5_d1K+KZaG+tQ@mail.gmail.com>
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
> On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
> <thomas_os@shipmail.org> wrote:
>> On 2/26/21 2:28 PM, Daniel Vetter wrote:
>>> So I think it stops gup. But I haven't verified at all. Would be good
>>> if Christian can check this with some direct io to a buffer in system
>>> memory.
>> Hmm,
>>
>> Docs (again vm_normal_page() say)
>>
>> * VM_MIXEDMAP mappings can likewise contain memory with or without "struct
>> * page" backing, however the difference is that _all_ pages with a struct
>> * page (that is, those where pfn_valid is true) are refcounted and
>> considered
>> * normal pages by the VM. The disadvantage is that pages are refcounted
>> * (which can be slower and simply not an option for some PFNMAP
>> users). The
>> * advantage is that we don't have to follow the strict linearity rule of
>> * PFNMAP mappings in order to support COWable mappings.
>>
>> but it's true __vm_insert_mixed() ends up in the insert_pfn() path, so
>> the above isn't really true, which makes me wonder if and in that case
>> why there could any longer ever be a significant performance difference
>> between MIXEDMAP and PFNMAP.
> Yeah it's definitely confusing. I guess I'll hack up a patch and see
> what sticks.
>
>> BTW regarding the TTM hugeptes, I don't think we ever landed that devmap
>> hack, so they are (for the non-gup case) relying on
>> vma_is_special_huge(). For the gup case, I think the bug is still there.
> Maybe there's another devmap hack, but the ttm_vm_insert functions do
> use PFN_DEV and all that. And I think that stops gup_fast from trying
> to find the underlying page.
> -Daniel
Hmm perhaps it might, but I don't think so. The fix I tried out was to set
PFN_DEV | PFN_MAP for huge PTEs which causes pfn_devmap() to be true,
and then
follow_devmap_pmd()->get_dev_pagemap() which returns NULL and gup_fast()
backs off,
in the end that would mean setting in stone that "if there is a huge
devmap page table entry for which we haven't registered any devmap
struct pages (get_dev_pagemap returns NULL), we should treat that as a
"special" huge page table entry".
From what I can tell, all code calling get_dev_pagemap() already does
that, it's just a question of getting it accepted and formalizing it.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström (Intel)" <thomas_os@shipmail.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
"Matthew Wilcox" <willy@infradead.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"John Stultz" <john.stultz@linaro.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Christian König" <christian.koenig@amd.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Date: Mon, 1 Mar 2021 09:39:53 +0100 [thread overview]
Message-ID: <b367b7e8-f202-4d23-d672-a5c9bc7fcec1@shipmail.org> (raw)
In-Reply-To: <CAKMK7uE=8+hj-MUFXHFoG_hAbz_Obi8a99+DE5_d1K+KZaG+tQ@mail.gmail.com>
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
> On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
> <thomas_os@shipmail.org> wrote:
>> On 2/26/21 2:28 PM, Daniel Vetter wrote:
>>> So I think it stops gup. But I haven't verified at all. Would be good
>>> if Christian can check this with some direct io to a buffer in system
>>> memory.
>> Hmm,
>>
>> Docs (again vm_normal_page() say)
>>
>> * VM_MIXEDMAP mappings can likewise contain memory with or without "struct
>> * page" backing, however the difference is that _all_ pages with a struct
>> * page (that is, those where pfn_valid is true) are refcounted and
>> considered
>> * normal pages by the VM. The disadvantage is that pages are refcounted
>> * (which can be slower and simply not an option for some PFNMAP
>> users). The
>> * advantage is that we don't have to follow the strict linearity rule of
>> * PFNMAP mappings in order to support COWable mappings.
>>
>> but it's true __vm_insert_mixed() ends up in the insert_pfn() path, so
>> the above isn't really true, which makes me wonder if and in that case
>> why there could any longer ever be a significant performance difference
>> between MIXEDMAP and PFNMAP.
> Yeah it's definitely confusing. I guess I'll hack up a patch and see
> what sticks.
>
>> BTW regarding the TTM hugeptes, I don't think we ever landed that devmap
>> hack, so they are (for the non-gup case) relying on
>> vma_is_special_huge(). For the gup case, I think the bug is still there.
> Maybe there's another devmap hack, but the ttm_vm_insert functions do
> use PFN_DEV and all that. And I think that stops gup_fast from trying
> to find the underlying page.
> -Daniel
Hmm perhaps it might, but I don't think so. The fix I tried out was to set
PFN_DEV | PFN_MAP for huge PTEs which causes pfn_devmap() to be true,
and then
follow_devmap_pmd()->get_dev_pagemap() which returns NULL and gup_fast()
backs off,
in the end that would mean setting in stone that "if there is a huge
devmap page table entry for which we haven't registered any devmap
struct pages (get_dev_pagemap returns NULL), we should treat that as a
"special" huge page table entry".
From what I can tell, all code calling get_dev_pagemap() already does
that, it's just a question of getting it accepted and formalizing it.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-03-01 8:41 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 10:59 [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap Daniel Vetter
2021-02-23 10:59 ` [Intel-gfx] " Daniel Vetter
2021-02-23 10:59 ` Daniel Vetter
2021-02-23 10:59 ` [PATCH 2/2] drm/vgem: use shmem helpers Daniel Vetter
2021-02-23 10:59 ` [Intel-gfx] " Daniel Vetter
2021-02-23 11:19 ` Thomas Zimmermann
2021-02-23 11:19 ` [Intel-gfx] " Thomas Zimmermann
2021-02-23 11:51 ` [PATCH] " Daniel Vetter
2021-02-23 11:51 ` [Intel-gfx] " Daniel Vetter
2021-02-23 14:21 ` [PATCH 2/2] " kernel test robot
2021-02-23 14:21 ` kernel test robot
2021-02-23 14:21 ` [Intel-gfx] " kernel test robot
2021-02-23 15:07 ` kernel test robot
2021-02-23 15:07 ` kernel test robot
2021-02-23 15:07 ` [Intel-gfx] " kernel test robot
2021-02-25 10:23 ` [PATCH] " Daniel Vetter
2021-02-25 10:23 ` [Intel-gfx] " Daniel Vetter
2021-02-26 9:19 ` Thomas Zimmermann
2021-02-26 9:19 ` [Intel-gfx] " Thomas Zimmermann
2021-02-26 13:30 ` Daniel Vetter
2021-02-26 13:30 ` [Intel-gfx] " Daniel Vetter
2021-02-26 13:51 ` Thomas Zimmermann
2021-02-26 13:51 ` [Intel-gfx] " Thomas Zimmermann
2021-02-26 14:04 ` Daniel Vetter
2021-02-26 14:04 ` [Intel-gfx] " Daniel Vetter
2021-02-23 11:19 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap Patchwork
2021-02-23 13:11 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev2) Patchwork
2021-02-24 7:46 ` [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap Thomas Hellström (Intel)
2021-02-24 7:46 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-02-24 7:46 ` Thomas Hellström (Intel)
2021-02-24 8:45 ` Daniel Vetter
2021-02-24 8:45 ` [Intel-gfx] " Daniel Vetter
2021-02-24 8:45 ` Daniel Vetter
2021-02-24 9:15 ` Thomas Hellström (Intel)
2021-02-24 9:15 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-02-24 9:15 ` Thomas Hellström (Intel)
2021-02-24 9:31 ` Daniel Vetter
2021-02-24 9:31 ` [Intel-gfx] " Daniel Vetter
2021-02-24 9:31 ` Daniel Vetter
2021-02-25 10:28 ` Christian König
2021-02-25 10:28 ` [Intel-gfx] " Christian König
2021-02-25 10:28 ` Christian König
2021-02-25 10:44 ` Daniel Vetter
2021-02-25 10:44 ` [Intel-gfx] " Daniel Vetter
2021-02-25 10:44 ` Daniel Vetter
2021-02-25 15:49 ` Daniel Vetter
2021-02-25 15:49 ` [Intel-gfx] " Daniel Vetter
2021-02-25 15:49 ` Daniel Vetter
2021-02-25 16:53 ` Christian König
2021-02-25 16:53 ` [Intel-gfx] " Christian König
2021-02-25 16:53 ` Christian König
2021-02-26 9:41 ` Thomas Hellström (Intel)
2021-02-26 9:41 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-02-26 9:41 ` Thomas Hellström (Intel)
2021-02-26 13:28 ` Daniel Vetter
2021-02-26 13:28 ` [Intel-gfx] " Daniel Vetter
2021-02-26 13:28 ` Daniel Vetter
2021-02-27 8:06 ` Thomas Hellström (Intel)
2021-02-27 8:06 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-02-27 8:06 ` Thomas Hellström (Intel)
2021-03-01 8:28 ` Daniel Vetter
2021-03-01 8:28 ` [Intel-gfx] " Daniel Vetter
2021-03-01 8:28 ` Daniel Vetter
2021-03-01 8:39 ` Thomas Hellström (Intel) [this message]
2021-03-01 8:39 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-03-01 8:39 ` Thomas Hellström (Intel)
2021-03-01 9:05 ` Daniel Vetter
2021-03-01 9:05 ` [Intel-gfx] " Daniel Vetter
2021-03-01 9:05 ` Daniel Vetter
2021-03-01 9:21 ` Thomas Hellström (Intel)
2021-03-01 9:21 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-03-01 9:21 ` Thomas Hellström (Intel)
2021-03-01 10:17 ` Christian König
2021-03-01 10:17 ` [Intel-gfx] " Christian König
2021-03-01 10:17 ` Christian König
2021-03-01 14:09 ` Daniel Vetter
2021-03-01 14:09 ` [Intel-gfx] " Daniel Vetter
2021-03-01 14:09 ` Daniel Vetter
2021-03-11 10:22 ` Thomas Hellström (Intel)
2021-03-11 10:22 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-03-11 10:22 ` Thomas Hellström (Intel)
2021-03-11 13:00 ` Daniel Vetter
2021-03-11 13:00 ` [Intel-gfx] " Daniel Vetter
2021-03-11 13:00 ` Daniel Vetter
2021-03-11 13:12 ` Thomas Hellström (Intel)
2021-03-11 13:12 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-03-11 13:12 ` Thomas Hellström (Intel)
2021-03-11 13:17 ` Daniel Vetter
2021-03-11 13:17 ` [Intel-gfx] " Daniel Vetter
2021-03-11 13:17 ` Daniel Vetter
2021-03-11 15:37 ` Thomas Hellström (Intel)
2021-03-11 15:37 ` [Intel-gfx] " Thomas Hellström (Intel)
2021-03-11 15:37 ` Thomas Hellström (Intel)
2021-03-12 7:51 ` Christian König
2021-03-12 7:51 ` [Intel-gfx] " Christian König
2021-03-12 7:51 ` Christian König
2021-02-24 18:46 ` Jason Gunthorpe
2021-02-24 18:46 ` Jason Gunthorpe
2021-02-25 10:30 ` Christian König
2021-02-25 10:30 ` [Intel-gfx] " Christian König
2021-02-25 10:30 ` Christian König
2021-02-25 10:45 ` Daniel Vetter
2021-02-25 10:45 ` [Intel-gfx] " Daniel Vetter
2021-02-25 10:45 ` Daniel Vetter
2021-02-25 10:38 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev3) Patchwork
2021-02-25 11:19 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-02-26 3:57 ` [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap John Stultz
2021-02-26 3:57 ` [Intel-gfx] " John Stultz
2021-02-26 3:57 ` John Stultz
2021-03-11 10:58 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [Linaro-mm-sig,1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev4) Patchwork
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=b367b7e8-f202-4d23-d672-a5c9bc7fcec1@shipmail.org \
--to=thomas_os@shipmail.org \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jgg@ziepe.ca \
--cc=john.stultz@linaro.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.