All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jason Gunthorpe <jgg@mellanox.com>,
	Ben Skeggs <bskeggs@redhat.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	Bharata B Rao <bharata@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, nouveau@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/9] mm: turn migrate_vma upside down
Date: Mon, 29 Jul 2019 19:43:12 -0400	[thread overview]
Message-ID: <20190729234312.GB7171@redhat.com> (raw)
In-Reply-To: <20190729142843.22320-2-hch@lst.de>

On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma.  Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks.  This removes a lot
> of boilerplate code as-is, and will allow the drivers to drastically
> improve code flow and error handling further on.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>


I haven't finished review, especialy the nouveau code, i will look
into this once i get back. In the meantime below are few corrections.

> ---
>  Documentation/vm/hmm.rst               |  55 +-----
>  drivers/gpu/drm/nouveau/nouveau_dmem.c | 122 +++++++------
>  include/linux/migrate.h                | 118 ++----------
>  mm/migrate.c                           | 242 +++++++++++--------------
>  4 files changed, 193 insertions(+), 344 deletions(-)
> 

[...]

> diff --git a/mm/migrate.c b/mm/migrate.c
> index 8992741f10aa..dc4e60a496f2 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2118,16 +2118,6 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
>  #endif /* CONFIG_NUMA */
>  
>  #if defined(CONFIG_MIGRATE_VMA_HELPER)
> -struct migrate_vma {
> -	struct vm_area_struct	*vma;
> -	unsigned long		*dst;
> -	unsigned long		*src;
> -	unsigned long		cpages;
> -	unsigned long		npages;
> -	unsigned long		start;
> -	unsigned long		end;
> -};
> -
>  static int migrate_vma_collect_hole(unsigned long start,
>  				    unsigned long end,
>  				    struct mm_walk *walk)
> @@ -2578,6 +2568,108 @@ static void migrate_vma_unmap(struct migrate_vma *migrate)
>  	}
>  }
>  
> +/**
> + * migrate_vma_setup() - prepare to migrate a range of memory
> + * @args: contains the vma, start, and and pfns arrays for the migration
> + *
> + * Returns: negative errno on failures, 0 when 0 or more pages were migrated
> + * without an error.
> + *
> + * Prepare to migrate a range of memory virtual address range by collecting all
> + * the pages backing each virtual address in the range, saving them inside the
> + * src array.  Then lock those pages and unmap them. Once the pages are locked
> + * and unmapped, check whether each page is pinned or not.  Pages that aren't
> + * pinned have the MIGRATE_PFN_MIGRATE flag set (by this function) in the
> + * corresponding src array entry.  Then restores any pages that are pinned, by
> + * remapping and unlocking those pages.
> + *
> + * The caller should then allocate destination memory and copy source memory to
> + * it for all those entries (ie with MIGRATE_PFN_VALID and MIGRATE_PFN_MIGRATE
> + * flag set).  Once these are allocated and copied, the caller must update each
> + * corresponding entry in the dst array with the pfn value of the destination
> + * page and with the MIGRATE_PFN_VALID and MIGRATE_PFN_LOCKED flags set
> + * (destination pages must have their struct pages locked, via lock_page()).
> + *
> + * Note that the caller does not have to migrate all the pages that are marked
> + * with MIGRATE_PFN_MIGRATE flag in src array unless this is a migration from
> + * device memory to system memory.  If the caller cannot migrate a device page
> + * back to system memory, then it must return VM_FAULT_SIGBUS, which will
> + * might have severe consequences for the userspace process, so it should best

      ^s/might//                                                      ^s/should best/must/

> + * be avoided if possible.
                 ^s/if possible//

Maybe adding something about failing only on unrecoverable device error. The
only reason we allow failure for migration here is because GPU devices can
go into bad state (GPU lockup) and when that happens the GPU memory might be
corrupted (power to GPU memory might be cut by GPU driver to recover the
GPU).

So failing migration back to main memory is only a last resort event.


> + *
> + * For empty entries inside CPU page table (pte_none() or pmd_none() is true) we
> + * do set MIGRATE_PFN_MIGRATE flag inside the corresponding source array thus
> + * allowing the caller to allocate device memory for those unback virtual
> + * address.  For this the caller simply havs to allocate device memory and
                                           ^ haves


  parent reply	other threads:[~2019-07-29 23:43 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 14:28 turn the hmm migrate_vma upside down Christoph Hellwig
2019-07-29 14:28 ` [PATCH 1/9] mm: turn " Christoph Hellwig
2019-07-29 23:12   ` Ralph Campbell
2019-07-29 23:12     ` Ralph Campbell
2019-07-29 23:43   ` Jerome Glisse [this message]
2019-07-31  1:46   ` Ralph Campbell
2019-07-31  1:46     ` Ralph Campbell
2019-08-01  7:42     ` Christoph Hellwig
2019-07-29 14:28 ` [PATCH 2/9] nouveau: reset dma_nr in nouveau_dmem_migrate_alloc_and_copy Christoph Hellwig
2019-07-29 23:18   ` Ralph Campbell
2019-07-29 23:18     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 3/9] nouveau: factor out device memory address calculation Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:21   ` Ralph Campbell
2019-07-29 23:21     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 4/9] nouveau: factor out dmem fence completion Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:23   ` Ralph Campbell
2019-07-29 23:23     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 5/9] nouveau: simplify nouveau_dmem_migrate_to_ram Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:26   ` Ralph Campbell
2019-07-29 23:26     ` Ralph Campbell
2019-07-31  9:57   ` Bharata B Rao
2019-08-01  7:46     ` Christoph Hellwig
2019-08-01  7:46       ` Christoph Hellwig
2019-07-29 14:28 ` [PATCH 6/9] nouveau: simplify nouveau_dmem_migrate_vma Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:27   ` Ralph Campbell
2019-07-29 23:27     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 7/9] mm: remove the unused MIGRATE_PFN_ERROR flag Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:29   ` Ralph Campbell
2019-07-29 23:29     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 8/9] mm: remove the unused MIGRATE_PFN_DEVICE flag Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:31   ` Ralph Campbell
2019-07-29 23:31     ` Ralph Campbell
2019-07-29 14:28 ` [PATCH 9/9] mm: remove the MIGRATE_PFN_WRITE flag Christoph Hellwig
2019-07-29 14:28   ` Christoph Hellwig
2019-07-29 23:30   ` Jerome Glisse
2019-07-30  5:46     ` Christoph Hellwig
2019-07-30  5:46       ` Christoph Hellwig
2019-07-30 15:51       ` Jerome Glisse
2019-07-29 23:42   ` Ralph Campbell
2019-07-29 23:42     ` Ralph Campbell
2019-07-29 23:46     ` Jerome Glisse
2019-07-30 12:32 ` turn the hmm migrate_vma upside down Jason Gunthorpe
2019-07-30 13:09   ` Christoph Hellwig
2019-08-08 15:33 turn hmm migrate_vma upside down v2 Christoph Hellwig
2019-08-08 15:33 ` [PATCH 1/9] mm: turn migrate_vma upside down Christoph Hellwig

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=20190729234312.GB7171@redhat.com \
    --to=jglisse@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bharata@linux.ibm.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=jgg@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rcampbell@nvidia.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.