On Fri, Aug 16, 2019 at 5:11 PM Christoph Hellwig wrote:
>
> On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
> >
> > On 8/10/19 4:13 AM, Christoph Hellwig wrote:
> >> On something vaguely related to this patch:
> >>
> >> You use the NVIF_VMM_PFNMAP_V0_V* defines from
On Tue, Aug 13, 2019 at 05:58:52PM -0400, Jerome Glisse wrote:
> On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> > When memory is migrated to the GPU it is likely to be accessed by GPU
> > code soon afterwards. Instead of waiting for a GPU fault, map the
> > migrated memory into
On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> When memory is migrated to the GPU it is likely to be accessed by GPU
> code soon afterwards. Instead of waiting for a GPU fault, map the
> migrated memory into the GPU page tables with the same access permissions
> as the source
On 8/10/19 4:13 AM, Christoph Hellwig wrote:
On something vaguely related to this patch:
You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
a little odd as we only ever set these bits, but they also don't seem
to appear to be in values that are directly fed to the
On 8/8/19 12:07 AM, Christoph Hellwig wrote:
On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
