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
e caught 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
---) which branch
or commit this 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
some point, we're going to make this 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
he the CPU, in that regard. My example 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
, and only 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
ose programming on devices that
have 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&#
as there
is only one caller of try_to_munlock.
- Alistair
No objections here. :)
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
unlock*" items to "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
Nouve
ut we 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.
asily write programs 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 ar
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
27;s better 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
mmit
description, 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
isabled: fallback 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
Nouve
N_VALID];
+ return pmd_write(pmd) ? (HMM_PFN_VALID | HMM_PFN_WRITE) : HMM_PFN_VALID;
I always found the previous range->flags[...] approach hard to remember, so it's
nice to see a simpler version now.
thanks,
--
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
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-by
>= are still 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)
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
(+), 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
validation should be
+* odd, not equal to the current invalidate_seq and
+ * invalidate_seq should not 'wrap' to the new seq any time
+* soon.
+*/
mrn->invalidate_seq = mmn_mm->invalidate_seq - 1;
interval_tree_insert(&mrn->interval_tree, &mmn_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
lidating(mmn_mm));
> + mrn->invalidate_seq = mmn_mm->invalidate_seq - 1;
Ohhh, checkmate. I lose. Why is *subtracting* the right thing to do
for seq numbers here? I'm acutely unhappy trying to figure this out.
I suspect it's another unfortunate side effect of trying to use th
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
));
> - 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, &iomem_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 "
is enabled, 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
that line 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
re-added as 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 i
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.
Reviewe
mutex_lock(&drm->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
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 Hubb
bdev, "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
ng). Then suballocate
from there 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 t
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:
>>>>
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 actu
erts respond. :)
thanks,
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
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
>
> Afte
45 matches
Mail list logo
