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
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
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
basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
Hi,
N
This is in order to avoid a forward declaration of
internal_get_user_pages_fast(), in the next patch.
This is code movement only--all generated code should
be identical.
Signed-off-by: John Hubbard
---
mm/gup.c | 112 +++
1 file changed, 56
arg. Also, if this series looks good, we can
ask Souptick to change the name as well, to whatever the consensus
is. My initial recommendation is: get_user_pages_fast_only(), to
match the new pin_user_pages_only().
John Hubbard (4):
mm/gup: move __get_user_pages_fast() down a few lines
This is the FOLL_PIN equivalent of __get_user_pages_fast(),
except with a more descriptive name, and gup_flags instead of
a boolean "write" in the argument list.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c | 36 +++
basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
driv
f enabling interrupts was fragile at best.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 1 +
mm/gup.c | 60 ++
2 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a5
umit Semwal
Cc: tee-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: John Hubbard
---
Note that I have only compile-tested this patch, although that does
also include cross-compiling for a few other arches.
thanks,
On 2020-05-18 22:18, John Hubbard wrote:
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
Lo
On 2020-05-21 12:11, John Hubbard wrote:
On 2020-05-21 11:57, Chris Wilson wrote:
Quoting John Hubbard (2020-05-19 01:21:20)
This needs to go through Andrew's -mm tree, due to adding a new gup.c
routine. However, I would really love to have some testing from the
drm/i915 folks, because I
On 2020-05-21 19:46, Chris Wilson wrote:
Quoting John Hubbard (2020-05-22 00:38:41)
Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
on, in internal_get_user_pages_fast().
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jani Nikula
Cc: "Joonas Lahtinen"
Cc: Ma
ko Ursulin
Signed-off-by: John Hubbard
---
Hi Andrew, Chris,
Andrew: This is a fixup that applies to today's (20200521) linux-next.
In that tree, this fixes up:
commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code")
Chris: I'd like to request another CI run for the
basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
driv
f enabling interrupts was fragile at best.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 1 +
mm/gup.c | 63 ++
2 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a5
to change the name as well, to whatever the consensus
is. My initial recommendation is: get_user_pages_fast_only(), to
match the new pin_user_pages_only().
John Hubbard (4):
mm/gup: move __get_user_pages_fast() down a few lines in gup.c
mm/gup: refactor and de-duplicate gup_fast() code
mm
This is the FOLL_PIN equivalent of __get_user_pages_fast(),
except with a more descriptive name, and gup_flags instead of
a boolean "write" in the argument list.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c | 36 +++
This is in order to avoid a forward declaration of
internal_get_user_pages_fast(), in the next patch.
This is code movement only--all generated code should
be identical.
Signed-off-by: John Hubbard
---
mm/gup.c | 112 +++
1 file changed, 56
Bergmann
Cc: Daniel Vetter
Cc: Gustavo A. R. Silva
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: John Hubbard
---
drivers/video/fbdev/pvr2fb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/pvr2
get one. And explain this with comments, seeing as
how it is error-prone.
Cc: Bartlomiej Zolnierkiewicz
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Gustavo A. R. Silva
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: John Hubbard
---
drivers/video
Vetter
Cc: Gustavo A. R. Silva
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
John Hubbard (2):
video: fbdev: fix error handling for get_user_pages_fast()
video: fbdev: convert get_user_pages() --> pin_user_pages()
drivers/video/fbdev/
On 2020-05-23 02:41, Chris Wilson wrote:
Quoting John Hubbard (2020-05-22 06:19:27)
The purpose of posting this series is to launch a test in the
intel-gfx-ci tree. (The patches have already been merged into Andrew's
linux-mm tree.)
This applies to today's linux.git (note the base-commit tag
On 2020-05-21 11:57, Chris Wilson wrote:
Quoting John Hubbard (2020-05-19 01:21:20)
This needs to go through Andrew's -mm tree, due to adding a new gup.c
routine. However, I would really love to have some testing from the
drm/i915 folks, because I haven't been able to run-time test that part
patch 1: you can further simplify by using
unpin_user_pages_dirty_lock().
list_del(>job_node);
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
On 10/7/20 9:44 AM, Daniel Vetter wrote:
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker
it was already done within
vma_set_file().
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/9/20 12:33 AM, Christian König wrote:
Am 08.10.20 um 23:49 schrieb John Hubbard:
On 10/8/20 4:23 AM, Christian König wrote:
...
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..c9d5f1a38af3 100644
--- a/drivers/gpu/drm
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
--
v2: Use
On 10/9/20 12:59 AM, Daniel Vetter wrote:
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc
less than
ret == nr_frames. And the whole partially pinned region idea turns out
to be just not useful for almost everyone, from what I recall of the gup/pup
call sites. So I wonder if we should just have get_vaddr_frames do the
cleanup here and return -EFAULT, if ret != nr_frames ?
thanks,
--
John H
lumsy
API design to *disable*, right?). And there is no hint about the scope.
And it *could* be so much more readable like this:
dev_access_enable(DEV_ACCESS_THIS_THREAD);
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freed
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc
the pup path out from the
mmap_sem critical section as suggested by Jason.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc
le for the same pte to already be there, ever? If so, we
be stuck in an infinite loop here. I'm sure that's not the case, but
it's not yet obvious to me why it's impossible. Resource reservations
maybe?
thanks,
--
John Hubbard
NVIDIA
___
dri-devel maili
On 10/7/20 2:32 PM, Daniel Vetter wrote:
On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote:
On 10/7/20 9:44 AM, Daniel Vetter wrote:
...
@@ -398,15 +399,11 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr-&
On 8/25/20 1:32 AM, Jens Wiklander wrote:
On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
...
OK, one more try, this time actually handling the _USER_MAPPED vs.
_KERNEL_MAPPED pages!
thanks,
John Hubbard
NVIDIA
Looks good and it works too! :-) I've tested it on my Hikey board
umit Semwal
Cc: tee-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: John Hubbard
---
OK, this should be indentical to v1 [1], but now rebased against
Linux 5.9-rc2.
As before, I've compile-tested it again with a cross
On 8/24/20 11:36 AM, John Hubbard wrote:
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
The
el.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: John Hubbard
---
OK, one more try, this time actually handling the _USER_MAPPED vs.
_KERNEL_MAPPED pages!
thanks,
John Hubbard
NVIDIA
drivers/tee/tee_shm.c | 32 +++-
1 file changed,
brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.
thanks,
--
John Hubbard
NVIDIA
There is already a dax specific check (added in b7f0554a56f2 ("mm:
fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
like the prudent thing to do.
Signed
On 10/3/20 2:45 AM, Daniel Vetter wrote:
On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
On 10/2/20 10:53 AM, Daniel Vetter wrote:
For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert get_user_
On 2020-05-27 01:51, Daniel Vetter wrote:
On Wed, May 27, 2020 at 10:48:52AM +0200, Daniel Vetter wrote:
On Tue, May 26, 2020 at 03:57:45PM -0700, John Hubbard wrote:
On 2020-05-26 14:00, Souptick Joarder wrote:
This code was using get_user_pages(), in a "Case 2" scenario
(DMA/RD
basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
H
umit Semwal
Cc: tee-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: John Hubbard
---
Hi,
This fixes the typo ("convert convert") in the subject line, but
otherwise no changes.
thanks,
John Hubbard
NVIDIA
.)
There were no *case 5* in the other patch posted in -mm. Do we need to add it ?
Working on figuring that out [1], but it's not directly relevant to this thread.
Maybe I shouldn't have brought it up here. :)
[1] https://lore.kernel.org/r/20200529070343.gl14...@quack2.suse.cz
thanks,
John Hubbard
On 2020-05-31 13:58, Sam Ravnborg wrote:
...
Thanks, patches are now applied to drm-misc-next.
They will hit -next soon, but you will have to wait
until next (not the upcoming) merge window before they hit
mainline linux.
Sam
Great! That will work out just fine.
thanks,
--
John
, as part of
commit 434502754f2 ("[PATCH] SH Merge")
...and that commit created the minor bug that patch 0001 here
addresses. (+Cc Paul just for the sake of completeness.)
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
thanks,
--
John Hubb
On 2020-06-01 10:25, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 8:10 PM John Hubbard wrote:
On 2020-06-01 03:35, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
On 2020-05-31 14:11, Andy Shevchenko wrote:
...
JFYI, we have history.git starting from v0.01
On 2020-06-01 03:35, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
On 2020-05-31 14:11, Andy Shevchenko wrote:
...
JFYI, we have history.git starting from v0.01.
OK, thanks for that note. According to that history.git [1],
then: drivers/video/pvr2fb.c had
/807108/
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
---
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ra
on
the latest linux-next (which has my changes now). Should be fine. And in
fact it would be nice to get that done in this round, so that the pin* and
get* APIs look the same.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel
ing. "Coyyntext" just doesn't sound as good. :)
:param num: Size of initial collection
:return: A random legal value for MR flags
"""
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing li
/O RESET_REG.
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
oliver.s...@intel.com
thanks,
--
John Hubbard
NVIDIA
___
Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc: Greg Kroah
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing from
pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up
losing the check
On 11/1/20 2:30 AM, Daniel Vetter wrote:
On Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote:
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing
about this:
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc
the remaining patches:
https://lore.kernel.org/dri-devel/1602799340-138152-1-git-send-email-jianxin.xi...@intel.com/
thanks,
--
John Hubbard
NVIDIA
v5:
* Fix a few warnings reported by kernel test robot:
- no previous prototype for function 'ib_umem_dmabuf_release'
- no previous
nly implementation that can pin pages. Thus it's still
* useful to have gup_huge_pmd even if we can't operate on ptes.
*/
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
not
seeing a pud_mkhugespecial anywhere. So not sure this works, but probably
just me missing something again.
It means ioremap can't create an IO page PUD, it has to be broken up.
Does ioremap even create anything larger than PTEs?
From my reading, yes. See ioremap_try_huge_pmd().
thanks,
--
John
the future of pinning to vidmem,
for this? It would allow a huge group of older GPUs and NICs and such to
do p2p with this approach, and it seems like a natural next step, right?
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel
s supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
unit?? This is a GPU, never anything else! Let's s/unit/gpu/ throughout, yes?
thanks,
--
John Hubbard
NVIDIA
+except PyverbsRDMAError as ex:
+
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
e GPU-like memory models.
thanks,
--
John Hubbard
NVIDIA
e was just one,
out
of a vast pool of possible behaviors.
thanks,
--
John Hubbard
NVIDIA
spinning another version for that, as it is still readable
as-is. Just mentioning it for the sake of pointless perfectionism, and in case
someone ever wonders why it was missed during a review. :) Either way, feel free
to add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff --git
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
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
to_munlock.
- Alistair
No objections here. :)
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
in
^FOLL_LONGTERM
ZONE_MOVEABLE before they're migrated) is still being worked on. So
not big benefits yet.
Yes. Great write-up, that's very clear, and it's exactly where we're at.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
Cc: John Hubbard
Signed-off-by: Daniel Vetter
Cc
sign point that we need to preserve, and fortunately it
doesn't conflict with anything I'm seeing here. But I want to say this out
loud because I see some doubt about it creeping into the discussion.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
this solution here for peer-to-peer. So I'm glad to see that
so far you're not ruling out the pinning option.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e here, if you drop this hunk then
it will make merging easier, I think.
[1] https://lore.kernel.org/r/20210813044133.1536842-4-jhubb...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
k we don't want to rule out that behavior, right? Or is the
thinking more like, "you're lucky that this old non-ODP setup works at
all, and we'll make it work by routing through host/cpu memory, but it
will be slow"?
thanks,
--
John Hubbard
NVIDIA
This is intentional since we don't w
ppening eg if the CPU touches it
later or something.
OK. I just want to avoid creating any API-level assumptions that dma_buf_pin()
necessarily implies or requires migrating to host memory.
thanks,
--
John Hubbard
NVIDIA
much about
providing first-class support for non-ODP setups.
I've got to drag my brain into 2021+! :)
thanks,
--
John Hubbard
NVIDIA
with Linus
if you go with the "cool" name here. :)
thanks,
--
John Hubbard
NVIDIA
omments into alignment with the code.
* I don't think memset deals properly with a zero length input arg, so
it's probably better to return 0, before that point.
thanks,
--
John Hubbard
NVIDIA
- if (args->start < args->vma->vm_start ||
- args->start &
whenever making changes to code
that deals with this:
nr_foll_pin_acquired
nr_foll_pin_released
...and those should normally be equal to each other when "at rest".
thanks,
--
John Hubbard
NVIDIA
+ else
put_page(pages[i]);
+
l_pin_acquired
nr_foll_pin_released
...and those should normally be equal to each other when "at rest".
I hope this is/was run, just to be sure?
thanks,
--
John Hubbard
NVIDIA
On 1/20/22 6:12 AM, Christoph Hellwig wrote:
On Tue, Jan 11, 2022 at 12:17:18AM -0800, John Hubbard wrote:
Zooming in on the pinning aspect for a moment: last time I attempted to
convert O_DIRECT callers from gup to pup, I recall wanting very much to
record, in each bio_vec, whether these pages
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
ooks quite helpful here). And also, user space will
need to open both /dev/dri/* and /dev/accel/* nodes, if it needs
access to anything live objects that drivers/accel owns.
thanks,
--
John Hubbard
NVIDIA
++---
mm/gup.c | 10 +-
mm/huge_memory.c | 2 +-
mm/hugetlb.c | 7 ---
4 files changed, 34 insertions(+), 12 deletions(-)
Looks good,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff --git a/include/linux/mm.h b/include/linux/mm.
ess: s/mapcount/refcount/ :)
whew, you had me going there! Now it all adds up. :)
thanks,
--
John Hubbard
NVIDIA
is to be using the
same nomenclature as the drm-vm-bind-async.rst.
Hi Thomas,
As requested, for the pin_user_pages() aspects (the MMU notifier
registration case), please feel free to add:
Acked-by: John Hubbard
v2:
- s/gvm/gpu_vm/g (Rodrigo Vivi)
- Clarify the userptr seqlock with a pointer to mm
601 - 692 of 692 matches
Mail list logo
