check and
the folio is unlocked without further changes.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: John Hubbard
Fixes: b756a3b5e7ea ("mm: device exclusive memory access")
Cc: sta...@vger.kernel.org
---
Changes for v2:
- Rebased to Linus master
- Rewor
ght that too. I plead spending too much
time recently in a somewhat more driver-centric mindset, and failing to
mentally shift gears properly for this case.
Sorry for missing that!
thanks,
--
John Hubbard
NVIDIA
his applies to, or let git format-patch help by passing in
the base commit via --base. That will save "some people" (people like
me) from having to guess, if they want to apply the patch locally and
poke around at it.
Anyway, all of the above are just little documentation and process
sugg
is all work with
file-backed memory, which will *definitely* not be discardable--I
realize that we're not there yet, of course.
But here, it's reasonable to commit to just retrying indefinitely,
really. Memory should eventually show up. And if it doesn't, then
restarting the machine is better than corrupting data, generally.
thanks,
--
John Hubbard
NVIDIA
e was just one,
out
of a vast pool of possible behaviors.
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
a tiny bit of (reduced!) data comes back
to the CPU. In that case, freeing the physical page on the CPU is actually the
best decision for the OS to make (if the OS is sufficiently prescient).
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouve
e GPU-like memory models.
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On 3/30/21 8:56 PM, John Hubbard wrote:
On 3/30/21 3:56 PM, Alistair Popple wrote:
...
+1 for renaming "munlock*" items to "mlock*", where applicable. good grief.
At least the situation was weird enough to prompt further investigation :)
Renaming to mlock* doesn't
to_munlock.
- Alistair
No objections here. :)
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
uot;mlock*", where applicable. good grief.
Although, it seems reasonable to tack such renaming patches onto the tail end
of this series. But whatever works.
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
can forcefully break this whenever we feel like by revoking
the page, moving it, and then reinstating the gpu pte again and let it
continue.
Oh yes, that's true.
If that's no possible then what we need here instead is an mlock() type of
thing I think.
No need for that, then.
thanks,
--
John
that do a long series of atomic
operations.
Such a program would be a little weird, but it's hard to rule out.
- long term pin: the page cannot be moved, all migration must fail.
Also this will have an impact on COW behaviour for fork (but not sure
where those patches are, John Hubbard will know
-5.8.0-rc2 and is for Ben Skeggs nouveau tree.
It doesn't depend on any of the other nouveau/HMM changes I have
recently posted.
Maybe cc stable, seeing as how the problem affect Linux 5.7?
thanks,
--
John Hubbard
NVIDIA
drivers/gpu/drm/nouveau/nouveau_svm.c | 1 +
1 file changed, 1 insertion(+)
*,
u64 addr, u64 size);
Looks accurate: the order within vmm.c (now that there is no .h
declaration) is still good, and I found no other uses of either function
within the linux.git tree, so
Reviewed-by: John Hubbard https://lists.freedesktop.org/mailman
r for
maintenance, too, because the function never intends to migrate "some
number of bytes". It intends to migrate exactly one page.
Hope I'm not missing something fundamental, but:
Reviewed-by: John Hubbard https://lists.freedesktop.org/mailman/listinfo/nouveau
cription, right? (It feels like a casualty of rearranging the patches.)
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
ck to base page
OK, but *all* page entries (base and huge/large pages) need to be cleared,
when migrating to device memory, unless I'm really confused here.
So: not CoW.
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop
return 0;
- return pmd_write(pmd) ? range->flags[HMM_PFN_VALID] |
- range->flags[HMM_PFN_WRITE] :
- range->flags[HMM_PFN_VALID];
+ return pmd_write(pmd) ? (HMM_PFN_VALID | HMM_PFN_WRITE) : HMM_PFN_VALID;
I
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
Acked-by: Felix Kuehling
Reviewed
ill at their input
* values.
*/
Either way,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
} while (ret == -EBUSY);
-
- if (ret)
- return ret;
- return (hmm_vma_walk.last - range->start) >> PAGE_SHIFT;
+ retu
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.
Yes, this is a nice touch.
Reviewed-by: John Hubbard
On 2/13/20 2:39 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote:
>> On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
>>> When calling debugfs functions, there is no need to ever check the
>>> return value. The function can work
, and simply return void
from the debugfs functions--rather than playing whack-a-mole with this
indefinitely?
thanks,
--
John Hubbard
NVIDIA
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Sig
rtions(+), 29 deletions(-)
>
Because this is correct as-is, you can add:
Reviewed-by: John Hubbard
...whether or not you take the following recommendation, which is:
you've only done part of the job of making struct mmu_notifier_mm
private to mmu_notifier.c. There's more:
* struct mmu
;invalidate_seq = mmn_mm->invalidate_seq - 1;
interval_tree_insert(>interval_tree, _mm->itree);
}
Looks good. We're just polishing up minor points now, so you can add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
ower bit of the seq number (even/odd) for something else.
> + interval_tree_insert(>interval_tree, _mm->itree);
> + }
> + spin_unlock(_mm->lock);
> + return 0;
> +}
> +
> +/**
> + * mmu_range_notifier_insert - Insert a range notifier
> + * @mrn: Range notifier to register
> + * @start: Starting virtual address to monitor
> + * @length: Length of the range to monitor
> + * @mm : mm_struct to attach to
> + *
> + * This function subscribes the range notifier for notifications from the mm.
> + * Upon return the ops related to mmu_range_notifier will be called whenever
> + * an event that intersects with the given range occurs.
> + *
> + * Upon return the range_notifier may not be present in the interval tree
> yet.
> + * The caller must use the normal range notifier locking flow via
> + * mmu_range_read_begin() to establish SPTEs for this range.
> + */
> +int mmu_range_notifier_insert(struct mmu_range_notifier *mrn,
> + unsigned long start, unsigned long length,
> + struct mm_struct *mm)
> +{
> + struct mmu_notifier_mm *mmn_mm;
> + int ret;
Hmmm, I think a later patch improperly changes the above to "int ret = 0;".
I'll check on that. It's correct here, though.
> +
> + might_lock(>mmap_sem);
> +
> + mmn_mm = smp_load_acquire(>mmu_notifier_mm);
What does the above pair with? Should have a comment that specifies that.
thanks,
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On 6/25/19 10:45 PM, Michal Hocko wrote:
> On Tue 25-06-19 20:15:28, John Hubbard wrote:
>> On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
>>> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>>>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>>>> On
On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
>>>> On Thu, Jun 13, 2019 at 12:53:02
device));
> - if (!devmem->resource)
> - return ERR_PTR(-ENOMEM);
> - break;
> - }
> - if (!devmem->resource)
> - return ERR_PTR(-ERANGE);
> -
> - devmem->resource->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
> + devmem->resource = devm_request_free_mem_region(device, _resource,
> + size);
> + if (IS_ERR(devmem->resource))
> + return ERR_CAST(devmem->resource);
> devmem->pfn_first = devmem->resource->start >> PAGE_SHIFT;
> devmem->pfn_last = devmem->pfn_first +
> (resource_size(devmem->resource) >> PAGE_SHIFT);
>
thanks,
--
John Hubbard
NVIDIA
On 6/14/19 10:39 AM, Ralph Campbell wrote:
> On 6/13/19 5:49 PM, John Hubbard wrote:
>> On 6/13/19 5:11 PM, Ralph Campbell wrote:
...
>> Actually, the pre-existing code is a little concerning. Your change preserves
>> the behavior, but it seems questionable to be doing a "
, then say Y.
config MIGRATE_VMA_HELPER
- bool
+ bool "migrate_vma() helper routine"
+ help
+ Provides a migrate_vma() routine that GPUs and other
+ device drivers may need.
config DEV_PAGEMAP_OPS
bool
thanks,
--
John Hubbard
NVIDIA
On 6/13/19 2:43 AM, Christoph Hellwig wrote:
> noveau is currently using this through an odd hmm wrapper, and I plan
"nouveau"
> to switch it to the real thing later in this series.
>
> Signed-off-by: Christoph Hellwig
> ---
Reviewed-by: John Hubbard
thanks
was unnecessary. I see from git history that it was
originally being set to NULL from within __put_devmap_managed_page(), and then
in commit 2fa147bdbf672c53386a8f5f2c7fe358004c3ef8, Dan moved it out of there,
and stashed in specifically here. But it appears to have been
s part of a future patchset to use that
kind of memory, but yes, we should not hesitate to clean house at this
point, and delete unused code.
thanks,
--
John Hubbard
NVIDIA
>
>>
>> So, yes, we really don't want any distro or something to turn this on
>> until it has a use.
&g
w that we've simplified the API for it.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/hmm.h | 3 ---
> mm/hmm.c| 54 -
> 2 files changed, 57 deletions(-)
>
No objections here, good cleanup.
Reviewed-by:
ex_lock(>dmem->mutex);
> continue;
> }
>
>
The above comment is about pre-existing potential problems, but your patch
itself
looks correct, so:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
nd it's a good housecleaning here.
(As to the history: I know that there was some early "HMM dummy device"
testing when the HMM code was much younger, but such testing has long since
been superseded by more elaborate testing with real drivers.)
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
N
r->subdev, "invalid secure boot blob!\n");
>> +kfree(bl_desc);
>> return -EINVAL;
>> }
>>
>>
Hi Gustavo,
Seeing as how I've been working on this corner of Nouveau lately (don't ask,
haha),
I reviewed and also tested this. It l
re using mmap's MAP_FIXED or (future-ish) MAP_FIXED_SAFE flags.
...glancing at the other fork of this thread, I think that is exactly
what
Felix is saying, too. So that's good.
-- The user space program sits above the user space driver, and although the
prog
On 01/28/2018 04:05 PM, Martin Peres wrote:
> On 29/01/18 01:24, Martin Peres wrote:
>> On 28/11/17 07:32, John Hubbard wrote:
>>> On 11/23/2017 02:48 PM, Martin Peres wrote:
>>>> On 23/11/17 10:06, John Hubbard wrote:
>>>>> On 11/22/
On 01/28/2018 04:05 PM, Martin Peres wrote:
> On 29/01/18 01:24, Martin Peres wrote:
>> On 28/11/17 07:32, John Hubbard wrote:
>>> On 11/23/2017 02:48 PM, Martin Peres wrote:
>>>> On 23/11/17 10:06, John Hubbard wrote:
>>>>> On 11/22/
On 11/23/2017 02:48 PM, Martin Peres wrote:
> On 23/11/17 10:06, John Hubbard wrote:
>> On 11/22/2017 05:07 PM, Martin Peres wrote:
>>> Hey,
>>>
>>> Thanks for your answer, Andy!
>>>
>>> On 22/11/17 04:06, Ilia Mirkin wrote:
>>>>
SKUs, given that some are inverted and others are not.
For the noisy GPUs, a very useful experiment would be to try inverting it,
like this:
pwmDutyCycle = pwmPeriod - pwmDutyCycle;
...and then see if fan control starts behaving closer to how you've actually
,
John Hubbard
NVIDIA
On 11/12/2017 06:29 PM, Martin Peres wrote:
> Hello,
>
> Some users have been complaining for years about their GPU sounding like
> a jet engine at take off. Last year, I finally laid my hand on one of
> these GPUs and have been trying to fix this issue o
early feedback: can you tell us the exact SKUs you have? And are these
production boards with production VBIOSes?
Normally, it's just our bringup boards that we'd expect to be noisy like
this, so we're looking for a few more details.
thanks,
John Hubbard
NVIDIA
>
> After failing to fi
45 matches
Mail list logo
