Displaying 6 results from an estimated 6 matches for "ib_reg_mr".
2020 Jan 16
2
[PATCH v6 5/6] nouveau: use new mmu interval notifiers
...p_sem);
> > > if (ret <= 0) {
> >
> > I'm still not sure this is a better approach than what ODP does. It
> > looks very expensive on the fault path..
> >
> > Jason
> >
>
> ODP doesn't have this problem because users have to call ib_reg_mr()
> before any I/O can happen to the process address space.
ODP supports a single 'full VA' call at process startup, just like
these cases.
> That is when mmu_interval_notifier_insert() /
> mmu_interval_notifier_remove() can be called and the driver doesn't
> have to worry...
2020 Jan 14
2
[PATCH v6 5/6] nouveau: use new mmu interval notifiers
On Mon, Jan 13, 2020 at 02:47:02PM -0800, Ralph Campbell wrote:
> void
> nouveau_svmm_fini(struct nouveau_svmm **psvmm)
> {
> struct nouveau_svmm *svmm = *psvmm;
> + struct mmu_interval_notifier *mni;
> +
> if (svmm) {
> mutex_lock(&svmm->mutex);
> + while (true) {
> + mni = mmu_interval_notifier_find(svmm->mm,
> +
2020 Jan 16
0
[PATCH v6 5/6] nouveau: use new mmu interval notifiers
...if (ret <= 0) {
>>>
>>> I'm still not sure this is a better approach than what ODP does. It
>>> looks very expensive on the fault path..
>>>
>>> Jason
>>>
>>
>> ODP doesn't have this problem because users have to call ib_reg_mr()
>> before any I/O can happen to the process address space.
>
> ODP supports a single 'full VA' call at process startup, just like
> these cases.
>
>> That is when mmu_interval_notifier_insert() /
>> mmu_interval_notifier_remove() can be called and the drive...
2020 Jan 15
0
[PATCH v6 5/6] nouveau: use new mmu interval notifiers
...ange, 0);
>> up_read(&mm->mmap_sem);
>> if (ret <= 0) {
>
> I'm still not sure this is a better approach than what ODP does. It
> looks very expensive on the fault path..
>
> Jason
>
ODP doesn't have this problem because users have to call ib_reg_mr()
before any I/O can happen to the process address space. That is when
mmu_interval_notifier_insert() / mmu_interval_notifier_remove() can
be called and the driver doesn't have to worry about the interval
changing sizes or being removed while I/O is happening.
For GPU like devices, I'm tryi...
2019 Jul 26
13
[PATCH v2 0/7] mm/hmm: more HMM clean up
Here are seven more patches for things I found to clean up.
This was based on top of Christoph's seven patches:
"hmm_range_fault related fixes and legacy API removal v3".
I assume this will go into Jason's tree since there will likely be
more HMM changes in this cycle.
Changes from v1 to v2:
Added AMD GPU to hmm_update removal.
Added 2 patches from Christoph.
Added 2 patches as
2019 Oct 28
32
[PATCH v2 00/15] Consolidate the mmu notifier interval_tree and locking
From: Jason Gunthorpe <jgg at mellanox.com>
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others