linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	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>,
	Jason Gunthorpe <jgg@nvidia.com>, Christoph Hellwig <hch@lst.de>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH v15 3/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios
Date: Fri, 14 Jun 2024 06:55:09 +0200	[thread overview]
Message-ID: <ZmvNLSUgUgFETR0M@localhost.localdomain> (raw)
In-Reply-To: <20240613214741.1029446-4-vivek.kasireddy@intel.com>

On Thu, Jun 13, 2024 at 02:42:05PM -0700, Vivek Kasireddy wrote:
> For drivers that would like to longterm-pin the folios associated
> with a memfd, the memfd_pin_folios() API provides an option to
> not only pin the folios via FOLL_PIN but also to check and migrate
> them if they reside in movable zone or CMA block. This API
> currently works with memfds but it should work with any files
> that belong to either shmemfs or hugetlbfs. Files belonging to
> other filesystems are rejected for now.
> 
> The folios 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.
> 
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> 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>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> (v2)
> Reviewed-by: David Hildenbrand <david@redhat.com> (v3)
> Reviewed-by: Christoph Hellwig <hch@lst.de> (v6)
> Acked-by: Dave Airlie <airlied@redhat.com>
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
...
> +struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> +	struct folio *folio;
> +	int err;
> +
> +	if (is_file_hugepages(memfd)) {
> +		folio = alloc_hugetlb_folio_nodemask(hstate_file(memfd),
> +						     NUMA_NO_NODE,
> +						     NULL,
> +						     GFP_USER,
> +						     false);

I dislike the direct use of GFP_USER there, because it opens the door for new
users to start passing their own GFP_ flags directly into hugetlb code, which
is not optimal, and something I would really like to prevent.

Hugetlb pages, until now, they have been mapped only to userspace and only used
in there, and they can or cannot be migrated based on its size, and that is why
we have 'htlb_alloc_mask'.

Now, you need something special because 1) these pages might need to be accessible by
some DMA driver, so you have HIGHMEM contraints and 2) cannot be migrated away.
Ok, but I see this as an exception, and it should really be called out
here.

 gfp_t = htlb_alloc_mask;

 /*
  * These pages will be accessible by a DMA driver, so we have zone memory
  * constraints where we can alloc from.
  * Also, these pages will be pinned for an undefinied amount of time, so do
  * not expect them to be able to be migrated away.
  */
 gfp &=  ~(__GFP_HIGHMEM | __GFP_MOVABLE)

So it is clear what is going on here.

-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2024-06-14  4:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13 21:42 [PATCH v15 0/9] " Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 1/9] mm/gup: Introduce unpin_folio/unpin_folios helpers Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 2/9] mm/gup: Introduce check_and_migrate_movable_folios() Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 3/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios Vivek Kasireddy
2024-06-14  4:55   ` Oscar Salvador [this message]
2024-06-18  6:49     ` Kasireddy, Vivek
2024-06-13 21:42 ` [PATCH v15 4/9] udmabuf: add CONFIG_MMU dependency Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 5/9] udmabuf: Use vmf_insert_pfn and VM_PFNMAP for handling mmap Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 6/9] udmabuf: Add back support for mapping hugetlb pages Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 7/9] udmabuf: Convert udmabuf driver to use folios Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 8/9] udmabuf: Pin the pages using memfd_pin_folios() API Vivek Kasireddy
2024-06-13 21:42 ` [PATCH v15 9/9] selftests/udmabuf: Add tests to verify data after page migration Vivek Kasireddy
2024-06-17 14:41 ` [PATCH v15 0/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios Daniel Vetter

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=ZmvNLSUgUgFETR0M@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=david@redhat.com \
    --cc=dongwon.kim@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=jgg@nvidia.com \
    --cc=junxiao.chang@intel.com \
    --cc=kraxel@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=vivek.kasireddy@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox