Re: [LSF/MM ATTEND] HMM (heterogeneous memory manager) and GPU

[Oded Gabbay <oded.gabbay@gmail.com>]

On Wed, Feb 3, 2016 at 2:40 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2016-01-28 at 18:55 +0100, Jerome Glisse wrote:
>>
>> I would like to attend LSF/MM this year to discuss about HMM
>> (Heterogeneous Memory Manager) and more generaly all topics
>> related to GPU and heterogeneous memory architecture (including
>> persistent memory).
>>
>> I want to discuss how to move forward with HMM merging and i
>> hope that by MM summit time i will be able to share more
>> informations publicly on devices which rely on HMM.
>
> There are a few related issues here around Shared Virtual Memory, and
> lifetime management of the associated MM, and the proposal discussed at
> the Kernel Summit for "off-CPU tasks".
>
> I've hit a situation with the Intel SVM code in 4.4 where the device
> driver binds a PASID, and also has mmap() functionality on the same
> file descriptor that the PASID is associated with.
>
> So on process exit, the MM doesn't die because the PASID binding still
> exists. The VMA of the mmap doesn't die because the MM still exists. So
> the underlying file remains open because the VMA still exists. And the
> PASID binding thus doesn't die because the file is still open.
>
Why connect the PASID to the FD in the first place ?
Why not tie everything to the MM ?

> I've posted a patch¹ which moves us closer to the amd_iommu_v2 model,
> although I'm still *strongly* resisting the temptation to call out into
> device driver code from the mmu_notifier's release callback.

You mean you are resisting doing this (taken from amdkfd):

--------------
static const struct mmu_notifier_ops kfd_process_mmu_notifier_ops = {
.release = kfd_process_notifier_release,
};

process->mmu_notifier.ops = &kfd_process_mmu_notifier_ops;
-----------

Why, if I may ask ?

Oded
>
> I would like to attend LSF/MM this year so we can continue to work on
> those issues — now that we actually have some hardware in the field and
> a better idea of how we can build a unified access model for SVM across
> the different IOMMU types.
>
> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse@intel.com                              Intel Corporation
>
>
> ¹ http://www.spinics.net/lists/linux-mm/msg100230.html

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>