All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	<linux-kernel@vger.kernel.org>,
	<iommu@lists.linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-api@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	<song.bao.hua@hisilicon.com>, <jgg@ziepe.ca>,
	<kevin.tian@intel.com>, <jean-philippe@linaro.org>,
	<eric.auger@redhat.com>, <liguozhu@hisilicon.com>,
	<zhangfei.gao@linaro.org>,
	Sihang Chen <chensihang1@hisilicon.com>
Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin
Date: Tue, 9 Feb 2021 20:20:18 +0800	[thread overview]
Message-ID: <2237506a-0c98-7ba6-5d5f-b60b637174c5@hisilicon.com> (raw)
In-Reply-To: <YCJ5k/Bxxkg3BNNj@kroah.com>

On 2021/2/9 20:01, Greg KH wrote:
> On Tue, Feb 09, 2021 at 07:58:15PM +0800, Zhou Wang wrote:
>> On 2021/2/9 17:37, Greg KH wrote:
>>> On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote:
>>>> On 2021/2/8 6:02, Andy Lutomirski wrote:
>>>>>
>>>>>
>>>>>> On Feb 7, 2021, at 12:31 AM, Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>>>>>
>>>>>> SVA(share virtual address) offers a way for device to share process virtual
>>>>>> address space safely, which makes more convenient for user space device
>>>>>> driver coding. However, IO page faults may happen when doing DMA
>>>>>> operations. As the latency of IO page fault is relatively big, DMA
>>>>>> performance will be affected severely when there are IO page faults.
>>>>>> From a long term view, DMA performance will be not stable.
>>>>>>
>>>>>> In high-performance I/O cases, accelerators might want to perform
>>>>>> I/O on a memory without IO page faults which can result in dramatically
>>>>>> increased latency. Current memory related APIs could not achieve this
>>>>>> requirement, e.g. mlock can only avoid memory to swap to backup device,
>>>>>> page migration can still trigger IO page fault.
>>>>>>
>>>>>> Various drivers working under traditional non-SVA mode are using
>>>>>> their own specific ioctl to do pin. Such ioctl can be seen in v4l2,
>>>>>> gpu, infiniband, media, vfio, etc. Drivers are usually doing dma
>>>>>> mapping while doing pin.
>>>>>>
>>>>>> But, in SVA mode, pin could be a common need which isn't necessarily
>>>>>> bound with any drivers, and neither is dma mapping needed by drivers
>>>>>> since devices are using the virtual address of CPU. Thus, It is better
>>>>>> to introduce a new common syscall for it.
>>>>>>
>>>>>> This patch leverages the design of userfaultfd and adds mempinfd for pin
>>>>>> to avoid messing up mm_struct. A fd will be got by mempinfd, then user
>>>>>> space can do pin/unpin pages by ioctls of this fd, all pinned pages under
>>>>>> one file will be unpinned in file release process. Like pin page cases in
>>>>>> other places, can_do_mlock is used to check permission and input
>>>>>> parameters.
>>>>>
>>>>>
>>>>> Can you document what the syscall does?
>>>>
>>>> Will add related document in Documentation/vm.
>>>
>>> A manpage is always good, and will be required eventually :)
>>
>> manpage is maintained in another repo. Do you mean add a manpage
>> patch in this series?
> 
> It's good to show how it will be used, don't you think?

Agree, will add it in next version.

Thanks,
Zhou

> 
> thanks,
> 
> greg k-h
> 
> .
> 


WARNING: multiple messages have this Message-ID (diff)
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: jean-philippe@linaro.org, kevin.tian@intel.com,
	Sihang Chen <chensihang1@hisilicon.com>,
	jgg@ziepe.ca, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@amacapital.net>,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	zhangfei.gao@linaro.org,
	Andrew Morton <akpm@linux-foundation.org>,
	liguozhu@hisilicon.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin
Date: Tue, 9 Feb 2021 20:20:18 +0800	[thread overview]
Message-ID: <2237506a-0c98-7ba6-5d5f-b60b637174c5@hisilicon.com> (raw)
In-Reply-To: <YCJ5k/Bxxkg3BNNj@kroah.com>

On 2021/2/9 20:01, Greg KH wrote:
> On Tue, Feb 09, 2021 at 07:58:15PM +0800, Zhou Wang wrote:
>> On 2021/2/9 17:37, Greg KH wrote:
>>> On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote:
>>>> On 2021/2/8 6:02, Andy Lutomirski wrote:
>>>>>
>>>>>
>>>>>> On Feb 7, 2021, at 12:31 AM, Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>>>>>
>>>>>> SVA(share virtual address) offers a way for device to share process virtual
>>>>>> address space safely, which makes more convenient for user space device
>>>>>> driver coding. However, IO page faults may happen when doing DMA
>>>>>> operations. As the latency of IO page fault is relatively big, DMA
>>>>>> performance will be affected severely when there are IO page faults.
>>>>>> From a long term view, DMA performance will be not stable.
>>>>>>
>>>>>> In high-performance I/O cases, accelerators might want to perform
>>>>>> I/O on a memory without IO page faults which can result in dramatically
>>>>>> increased latency. Current memory related APIs could not achieve this
>>>>>> requirement, e.g. mlock can only avoid memory to swap to backup device,
>>>>>> page migration can still trigger IO page fault.
>>>>>>
>>>>>> Various drivers working under traditional non-SVA mode are using
>>>>>> their own specific ioctl to do pin. Such ioctl can be seen in v4l2,
>>>>>> gpu, infiniband, media, vfio, etc. Drivers are usually doing dma
>>>>>> mapping while doing pin.
>>>>>>
>>>>>> But, in SVA mode, pin could be a common need which isn't necessarily
>>>>>> bound with any drivers, and neither is dma mapping needed by drivers
>>>>>> since devices are using the virtual address of CPU. Thus, It is better
>>>>>> to introduce a new common syscall for it.
>>>>>>
>>>>>> This patch leverages the design of userfaultfd and adds mempinfd for pin
>>>>>> to avoid messing up mm_struct. A fd will be got by mempinfd, then user
>>>>>> space can do pin/unpin pages by ioctls of this fd, all pinned pages under
>>>>>> one file will be unpinned in file release process. Like pin page cases in
>>>>>> other places, can_do_mlock is used to check permission and input
>>>>>> parameters.
>>>>>
>>>>>
>>>>> Can you document what the syscall does?
>>>>
>>>> Will add related document in Documentation/vm.
>>>
>>> A manpage is always good, and will be required eventually :)
>>
>> manpage is maintained in another repo. Do you mean add a manpage
>> patch in this series?
> 
> It's good to show how it will be used, don't you think?

Agree, will add it in next version.

Thanks,
Zhou

> 
> thanks,
> 
> greg k-h
> 
> .
> 

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: song.bao.hua@hisilicon.com, jean-philippe@linaro.org,
	kevin.tian@intel.com, Sihang Chen <chensihang1@hisilicon.com>,
	jgg@ziepe.ca, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@amacapital.net>,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	eric.auger@redhat.com, zhangfei.gao@linaro.org,
	Andrew Morton <akpm@linux-foundation.org>,
	liguozhu@hisilicon.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin
Date: Tue, 9 Feb 2021 20:20:18 +0800	[thread overview]
Message-ID: <2237506a-0c98-7ba6-5d5f-b60b637174c5@hisilicon.com> (raw)
In-Reply-To: <YCJ5k/Bxxkg3BNNj@kroah.com>

On 2021/2/9 20:01, Greg KH wrote:
> On Tue, Feb 09, 2021 at 07:58:15PM +0800, Zhou Wang wrote:
>> On 2021/2/9 17:37, Greg KH wrote:
>>> On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote:
>>>> On 2021/2/8 6:02, Andy Lutomirski wrote:
>>>>>
>>>>>
>>>>>> On Feb 7, 2021, at 12:31 AM, Zhou Wang <wangzhou1@hisilicon.com> wrote:
>>>>>>
>>>>>> SVA(share virtual address) offers a way for device to share process virtual
>>>>>> address space safely, which makes more convenient for user space device
>>>>>> driver coding. However, IO page faults may happen when doing DMA
>>>>>> operations. As the latency of IO page fault is relatively big, DMA
>>>>>> performance will be affected severely when there are IO page faults.
>>>>>> From a long term view, DMA performance will be not stable.
>>>>>>
>>>>>> In high-performance I/O cases, accelerators might want to perform
>>>>>> I/O on a memory without IO page faults which can result in dramatically
>>>>>> increased latency. Current memory related APIs could not achieve this
>>>>>> requirement, e.g. mlock can only avoid memory to swap to backup device,
>>>>>> page migration can still trigger IO page fault.
>>>>>>
>>>>>> Various drivers working under traditional non-SVA mode are using
>>>>>> their own specific ioctl to do pin. Such ioctl can be seen in v4l2,
>>>>>> gpu, infiniband, media, vfio, etc. Drivers are usually doing dma
>>>>>> mapping while doing pin.
>>>>>>
>>>>>> But, in SVA mode, pin could be a common need which isn't necessarily
>>>>>> bound with any drivers, and neither is dma mapping needed by drivers
>>>>>> since devices are using the virtual address of CPU. Thus, It is better
>>>>>> to introduce a new common syscall for it.
>>>>>>
>>>>>> This patch leverages the design of userfaultfd and adds mempinfd for pin
>>>>>> to avoid messing up mm_struct. A fd will be got by mempinfd, then user
>>>>>> space can do pin/unpin pages by ioctls of this fd, all pinned pages under
>>>>>> one file will be unpinned in file release process. Like pin page cases in
>>>>>> other places, can_do_mlock is used to check permission and input
>>>>>> parameters.
>>>>>
>>>>>
>>>>> Can you document what the syscall does?
>>>>
>>>> Will add related document in Documentation/vm.
>>>
>>> A manpage is always good, and will be required eventually :)
>>
>> manpage is maintained in another repo. Do you mean add a manpage
>> patch in this series?
> 
> It's good to show how it will be used, don't you think?

Agree, will add it in next version.

Thanks,
Zhou

> 
> thanks,
> 
> greg k-h
> 
> .
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-02-09 12:21 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07  8:18 [RFC PATCH v3 0/2] mempinfd: Add new syscall to provide memory pin Zhou Wang
2021-02-07  8:18 ` Zhou Wang
2021-02-07  8:18 ` Zhou Wang
2021-02-07  8:18 ` [RFC PATCH v3 1/2] " Zhou Wang
2021-02-07  8:18   ` Zhou Wang
2021-02-07  8:18   ` Zhou Wang
2021-02-07 10:51   ` kernel test robot
2021-02-07 10:59   ` kernel test robot
2021-02-07 21:34   ` Matthew Wilcox
2021-02-07 21:34     ` Matthew Wilcox
2021-02-07 21:34     ` Matthew Wilcox
2021-02-07 22:24     ` Song Bao Hua (Barry Song)
2021-02-07 22:24       ` Song Bao Hua (Barry Song)
2021-02-07 22:24       ` Song Bao Hua (Barry Song)
2021-02-07 22:24       ` Song Bao Hua (Barry Song)
2021-02-08  1:30       ` Matthew Wilcox
2021-02-08  1:30         ` Matthew Wilcox
2021-02-08  1:30         ` Matthew Wilcox
2021-02-08  1:30         ` Matthew Wilcox
2021-02-08  2:27         ` Song Bao Hua (Barry Song)
2021-02-08  2:27           ` Song Bao Hua (Barry Song)
2021-02-08  2:27           ` Song Bao Hua (Barry Song)
2021-02-08  2:27           ` Song Bao Hua (Barry Song)
2021-02-08  3:46           ` Hillf Danton
2021-02-08  8:21           ` David Hildenbrand
2021-02-08  8:21             ` David Hildenbrand
2021-02-08  8:21             ` David Hildenbrand
2021-02-08  8:21             ` David Hildenbrand
2021-02-08 10:13             ` Song Bao Hua (Barry Song)
2021-02-08 10:13               ` Song Bao Hua (Barry Song)
2021-02-08 10:13               ` Song Bao Hua (Barry Song)
2021-02-08 10:13               ` Song Bao Hua (Barry Song)
2021-02-08 10:37               ` David Hildenbrand
2021-02-08 10:37                 ` David Hildenbrand
2021-02-08 10:37                 ` David Hildenbrand
2021-02-08 10:37                 ` David Hildenbrand
2021-02-08 20:52                 ` Song Bao Hua (Barry Song)
2021-02-08 20:52                   ` Song Bao Hua (Barry Song)
2021-02-08 20:52                   ` Song Bao Hua (Barry Song)
2021-02-08 20:52                   ` Song Bao Hua (Barry Song)
2021-02-08  2:18       ` David Rientjes
2021-02-08  2:18         ` David Rientjes
2021-02-08  2:18         ` David Rientjes via iommu
2021-02-08  2:18         ` David Rientjes
2021-02-08  5:34         ` Song Bao Hua (Barry Song)
2021-02-08  5:34           ` Song Bao Hua (Barry Song)
2021-02-08  5:34           ` Song Bao Hua (Barry Song)
2021-02-08  5:34           ` Song Bao Hua (Barry Song)
2021-02-09  9:02     ` Zhou Wang
2021-02-09  9:02       ` Zhou Wang
2021-02-07 21:51   ` Arnd Bergmann
2021-02-07 21:51     ` Arnd Bergmann
2021-02-07 21:51     ` Arnd Bergmann
2021-02-07 21:51     ` Arnd Bergmann
2021-02-09  9:27     ` Zhou Wang
2021-02-09  9:27       ` Zhou Wang
2021-02-09  9:27       ` Zhou Wang
2021-02-07 22:02   ` Andy Lutomirski
2021-02-07 22:02     ` Andy Lutomirski
2021-02-07 22:02     ` Andy Lutomirski
2021-02-09  9:17     ` Zhou Wang
2021-02-09  9:17       ` Zhou Wang
2021-02-09  9:17       ` Zhou Wang
2021-02-09  9:37       ` Greg KH
2021-02-09  9:37         ` Greg KH
2021-02-09  9:37         ` Greg KH
2021-02-09 11:58         ` Zhou Wang
2021-02-09 11:58           ` Zhou Wang
2021-02-09 11:58           ` Zhou Wang
2021-02-09 12:01           ` Greg KH
2021-02-09 12:01             ` Greg KH
2021-02-09 12:01             ` Greg KH
2021-02-09 12:20             ` Zhou Wang [this message]
2021-02-09 12:20               ` Zhou Wang
2021-02-09 12:20               ` Zhou Wang
2021-02-10 18:50               ` Matthew Wilcox
2021-02-10 18:50                 ` Matthew Wilcox
2021-02-10 18:50                 ` Matthew Wilcox
2021-02-08  8:14   ` David Hildenbrand
2021-02-08  8:14     ` David Hildenbrand
2021-02-08  8:14     ` David Hildenbrand
2021-02-08 18:33     ` Jason Gunthorpe
2021-02-08 18:33       ` Jason Gunthorpe
2021-02-08 18:33       ` Jason Gunthorpe
2021-02-08 20:35       ` Song Bao Hua (Barry Song)
2021-02-08 20:35         ` Song Bao Hua (Barry Song)
2021-02-08 20:35         ` Song Bao Hua (Barry Song)
2021-02-08 20:35         ` Song Bao Hua (Barry Song)
2021-02-08 21:30         ` Jason Gunthorpe
2021-02-08 21:30           ` Jason Gunthorpe
2021-02-08 21:30           ` Jason Gunthorpe
2021-02-08 21:30           ` Jason Gunthorpe
2021-02-09  3:01           ` Song Bao Hua (Barry Song)
2021-02-09  3:01             ` Song Bao Hua (Barry Song)
2021-02-09  3:01             ` Song Bao Hua (Barry Song)
2021-02-09  3:01             ` Song Bao Hua (Barry Song)
2021-02-09 13:53             ` Jason Gunthorpe
2021-02-09 13:53               ` Jason Gunthorpe
2021-02-09 13:53               ` Jason Gunthorpe
2021-02-09 13:53               ` Jason Gunthorpe
2021-02-09 22:22               ` Song Bao Hua (Barry Song)
2021-02-09 22:22                 ` Song Bao Hua (Barry Song)
2021-02-09 22:22                 ` Song Bao Hua (Barry Song)
2021-02-09 22:22                 ` Song Bao Hua (Barry Song)
2021-02-10 18:04                 ` Jason Gunthorpe
2021-02-10 18:04                   ` Jason Gunthorpe
2021-02-10 18:04                   ` Jason Gunthorpe
2021-02-10 18:04                   ` Jason Gunthorpe
2021-02-10 21:39                   ` Song Bao Hua (Barry Song)
2021-02-10 21:39                     ` Song Bao Hua (Barry Song)
2021-02-10 21:39                     ` Song Bao Hua (Barry Song)
2021-02-10 21:39                     ` Song Bao Hua (Barry Song)
2021-02-11 10:28                     ` David Hildenbrand
2021-02-11 10:28                       ` David Hildenbrand
2021-02-11 10:28                       ` David Hildenbrand
2021-02-11 10:28                       ` David Hildenbrand
2021-02-07  8:18 ` [RFC PATCH v3 2/2] selftests/vm: add mempinfd test Zhou Wang
2021-02-07  8:18   ` Zhou Wang
2021-02-07  8:18   ` Zhou Wang

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=2237506a-0c98-7ba6-5d5f-b60b637174c5@hisilicon.com \
    --to=wangzhou1@hisilicon.com \
    --cc=akpm@linux-foundation.org \
    --cc=chensihang1@hisilicon.com \
    --cc=eric.auger@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@ziepe.ca \
    --cc=kevin.tian@intel.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=song.bao.hua@hisilicon.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zhangfei.gao@linaro.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.