From: Jason Gunthorpe <jgg@nvidia.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
Dongwon Kim <dongwon.kim@intel.com>,
David Hildenbrand <david@redhat.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Hugh Dickins <hughd@google.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Peter Xu <peterx@redhat.com>,
Junxiao Chang <junxiao.chang@intel.com>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2)
Date: Mon, 6 Nov 2023 13:48:10 -0400 [thread overview]
Message-ID: <20231106174810.GI4488@nvidia.com> (raw)
In-Reply-To: <20231106061541.507116-2-vivek.kasireddy@intel.com>
On Sun, Nov 05, 2023 at 10:15:39PM -0800, Vivek Kasireddy wrote:
> For drivers that would like to longterm-pin the pages associated
> with a file, the pin_user_pages_fd() API provides an option to
> not only pin the pages via FOLL_PIN but also to check and migrate
> them if they reside in movable zone or CMA block. This API
> currently works with files that belong to either shmem or hugetlbfs.
> Files belonging to other filesystems are rejected for now.
>
> The pages need to be located first before pinning them via FOLL_PIN.
> If they are found in the page cache, they can be immediately pinned.
> Otherwise, they need to be allocated using the filesystem specific
> APIs and then pinned.
>
> v2:
> - Drop gup_flags and improve comments and commit message (David)
> - Allocate a page if we cannot find in page cache for the hugetlbfs
> case as well (David)
> - Don't unpin pages if there is a migration related failure (David)
> - Drop the unnecessary nr_pages <= 0 check (Jason)
> - Have the caller of the API pass in file * instead of fd (Jason)
>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Dongwon Kim <dongwon.kim@intel.com>
> Cc: Junxiao Chang <junxiao.chang@intel.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
> include/linux/mm.h | 2 +
> mm/gup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 101 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
David Hildenbrand <david@redhat.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Mike Kravetz <mike.kravetz@oracle.com>,
Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Dongwon Kim <dongwon.kim@intel.com>,
Junxiao Chang <junxiao.chang@intel.com>
Subject: Re: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2)
Date: Mon, 6 Nov 2023 13:48:10 -0400 [thread overview]
Message-ID: <20231106174810.GI4488@nvidia.com> (raw)
In-Reply-To: <20231106061541.507116-2-vivek.kasireddy@intel.com>
On Sun, Nov 05, 2023 at 10:15:39PM -0800, Vivek Kasireddy wrote:
> For drivers that would like to longterm-pin the pages associated
> with a file, the pin_user_pages_fd() API provides an option to
> not only pin the pages via FOLL_PIN but also to check and migrate
> them if they reside in movable zone or CMA block. This API
> currently works with files that belong to either shmem or hugetlbfs.
> Files belonging to other filesystems are rejected for now.
>
> The pages need to be located first before pinning them via FOLL_PIN.
> If they are found in the page cache, they can be immediately pinned.
> Otherwise, they need to be allocated using the filesystem specific
> APIs and then pinned.
>
> v2:
> - Drop gup_flags and improve comments and commit message (David)
> - Allocate a page if we cannot find in page cache for the hugetlbfs
> case as well (David)
> - Don't unpin pages if there is a migration related failure (David)
> - Drop the unnecessary nr_pages <= 0 check (Jason)
> - Have the caller of the API pass in file * instead of fd (Jason)
>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Dongwon Kim <dongwon.kim@intel.com>
> Cc: Junxiao Chang <junxiao.chang@intel.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
> include/linux/mm.h | 2 +
> mm/gup.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 101 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
next prev parent reply other threads:[~2023-11-06 17:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 6:15 [PATCH v2 0/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2) Vivek Kasireddy
2023-11-06 6:15 ` Vivek Kasireddy
2023-11-06 6:15 ` [PATCH v2 1/3] " Vivek Kasireddy
2023-11-06 6:15 ` Vivek Kasireddy
2023-11-06 17:48 ` Jason Gunthorpe [this message]
2023-11-06 17:48 ` Jason Gunthorpe
2023-11-07 3:33 ` kernel test robot
2023-11-07 3:33 ` kernel test robot
2023-11-07 4:40 ` kernel test robot
2023-11-07 4:40 ` kernel test robot
2023-11-13 10:33 ` David Hildenbrand
2023-11-13 10:33 ` David Hildenbrand
2023-11-14 7:00 ` [PATCH] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v3) Vivek Kasireddy
2023-11-14 7:00 ` Vivek Kasireddy
2023-11-14 9:23 ` David Hildenbrand
2023-11-14 9:23 ` David Hildenbrand
2023-11-06 6:15 ` [PATCH v2 2/3] udmabuf: Pin the pages using pin_user_pages_fd() API (v2) Vivek Kasireddy
2023-11-06 6:15 ` Vivek Kasireddy
2023-11-06 6:15 ` [PATCH v2 3/3] selftests/dma-buf/udmabuf: Add tests to verify data after page migration Vivek Kasireddy
2023-11-06 6:15 ` Vivek Kasireddy
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=20231106174810.GI4488@nvidia.com \
--to=jgg@nvidia.com \
--cc=daniel.vetter@ffwll.ch \
--cc=david@redhat.com \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hughd@google.com \
--cc=junxiao.chang@intel.com \
--cc=kraxel@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=peterx@redhat.com \
--cc=vivek.kasireddy@intel.com \
/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.