All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: Felix Kuehling <felix.kuehling@gmail.com>,
	amd-gfx@lists.freedesktop.org, linux-mm@kvack.org,
	jglisse@redhat.com, dri-devel@lists.freedesktop.org,
	Jason Gunthorpe <jgg@nvidia.com>,
	akpm@linux-foundation.org, hch@lst.de
Subject: Re: [RFC PATCH 0/5] Support DEVICE_GENERIC memory in migrate_vma_*
Date: Sat, 29 May 2021 08:41:24 +0200	[thread overview]
Message-ID: <20210529064124.GC15834@lst.de> (raw)
In-Reply-To: <f0bb142b-ab80-c16e-77dd-c7e1aa88c755@amd.com>

On Fri, May 28, 2021 at 11:56:36AM -0400, Felix Kuehling wrote:
> Am 2021-05-28 um 9:08 a.m. schrieb Jason Gunthorpe:
> > On Thu, May 27, 2021 at 07:08:04PM -0400, Felix Kuehling wrote:
> >> Now we're trying to migrate data to and from that memory using the
> >> migrate_vma_* helpers so we can support page-based migration in our
> >> unified memory allocations, while also supporting CPU access to those
> >> pages.
> > So you have completely coherent and indistinguishable GPU and CPU
> > memory and the need of migration is basicaly alot like NUMA policy
> > choice - get better access locality?
> 
> Yes. For a typical GPU compute application it means the GPU gets the
> best bandwidth/latency, and the CPU can coherently access the results
> without page faults and migrations. That's especially valuable for
> applications with persistent compute kernels that want to exploit
> concurrency between CPU and GPU.

So why not expose the GPU memory as a CPUless memory node?
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	Felix Kuehling <felix.kuehling@gmail.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	jglisse@redhat.com, amd-gfx@lists.freedesktop.org,
	akpm@linux-foundation.org, hch@lst.de
Subject: Re: [RFC PATCH 0/5] Support DEVICE_GENERIC memory in migrate_vma_*
Date: Sat, 29 May 2021 08:41:24 +0200	[thread overview]
Message-ID: <20210529064124.GC15834@lst.de> (raw)
In-Reply-To: <f0bb142b-ab80-c16e-77dd-c7e1aa88c755@amd.com>

On Fri, May 28, 2021 at 11:56:36AM -0400, Felix Kuehling wrote:
> Am 2021-05-28 um 9:08 a.m. schrieb Jason Gunthorpe:
> > On Thu, May 27, 2021 at 07:08:04PM -0400, Felix Kuehling wrote:
> >> Now we're trying to migrate data to and from that memory using the
> >> migrate_vma_* helpers so we can support page-based migration in our
> >> unified memory allocations, while also supporting CPU access to those
> >> pages.
> > So you have completely coherent and indistinguishable GPU and CPU
> > memory and the need of migration is basicaly alot like NUMA policy
> > choice - get better access locality?
> 
> Yes. For a typical GPU compute application it means the GPU gets the
> best bandwidth/latency, and the CPU can coherently access the results
> without page faults and migrations. That's especially valuable for
> applications with persistent compute kernels that want to exploit
> concurrency between CPU and GPU.

So why not expose the GPU memory as a CPUless memory node?


  reply	other threads:[~2021-05-29 10:20 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 23:08 [RFC PATCH 0/5] Support DEVICE_GENERIC memory in migrate_vma_* Felix Kuehling
2021-05-27 23:08 ` Felix Kuehling
2021-05-27 23:08 ` Felix Kuehling
2021-05-27 23:08 ` [RFC PATCH 1/5] drm/amdkfd: add SPM support for SVM Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-29  6:38   ` Christoph Hellwig
2021-05-29  6:38     ` Christoph Hellwig
2021-05-29 18:42     ` Felix Kuehling
2021-05-29 18:42       ` Felix Kuehling
2021-05-29 18:42       ` Felix Kuehling
2021-05-27 23:08 ` [RFC PATCH 2/5] drm/amdkfd: generic type as sys mem on migration to ram Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08 ` [RFC PATCH 3/5] include/linux/mm.h: helper to check zone device generic type Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08 ` [RFC PATCH 4/5] mm: add generic type support for device zone page migration Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-29  6:40   ` Christoph Hellwig
2021-05-29  6:40     ` Christoph Hellwig
2021-05-27 23:08 ` [RFC PATCH 5/5] mm: changes to unref pages with Generic type Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-27 23:08   ` Felix Kuehling
2021-05-29  6:42   ` Christoph Hellwig
2021-05-29  6:42     ` Christoph Hellwig
2021-05-29 18:44     ` Felix Kuehling
2021-05-29 18:44       ` Felix Kuehling
2021-05-29 18:44       ` Felix Kuehling
2021-05-28 13:08 ` [RFC PATCH 0/5] Support DEVICE_GENERIC memory in migrate_vma_* Jason Gunthorpe
2021-05-28 13:08   ` Jason Gunthorpe
2021-05-28 13:08   ` Jason Gunthorpe
2021-05-28 15:56   ` Felix Kuehling
2021-05-28 15:56     ` Felix Kuehling
2021-05-28 15:56     ` Felix Kuehling
2021-05-29  6:41     ` Christoph Hellwig [this message]
2021-05-29  6:41       ` Christoph Hellwig
2021-05-29 18:37       ` Felix Kuehling
2021-05-29 18:37         ` Felix Kuehling
2021-05-29 18:37         ` Felix Kuehling

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=20210529064124.GC15834@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=felix.kuehling@gmail.com \
    --cc=jgg@nvidia.com \
    --cc=jglisse@redhat.com \
    --cc=linux-mm@kvack.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.