nctionality to
work in a narrow situation. It has a high performance penalty and
narrow HW support.
So yes, compute boards are routinely used in scenarios where ODP is
not available, today and for the foreseeable future.
Jason
On Wed, Aug 25, 2021 at 07:59:27AM +0300, Maor Gottlieb wrote:
>
> On 8/24/2021 10:12 PM, Jason Gunthorpe wrote:
> > On Tue, Aug 24, 2021 at 05:25:30PM +0300, Maor Gottlieb wrote:
> > > @@ -514,11 +531,13 @@ struct scatterlist
> > > *sg_alloc_append_table_f
On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote:
> Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> > > Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > > > On Wed, Aug 25, 2021
inrs are
covered under the ulimit (IIRC), so the driver to do this work might
not be so strong.
Jason
t;
> Hopefully adding RFC stuff doesnt distract too much.
Hi Jim,
Yeah, I feel like the RFC patches should be in a separate series
unless there is a drm dependency for them?
Thanks,
-Jason
>
> Jim Cromie (11):
> moduleparam: add data member to struct kernel_param
> dyn
atch entirely?
define something like:
struct dd_bitmap_param {
int bitmap;
struct dyndbg_bitdesc *bitmap_arr;
};
and then just pass a pointer to it as 'arg' for module_param_cb? And then in
the get/set callbacks you can use kp->bitmap and kp->bitmap_arr.
Thanks,
-Ja
IES
> + */
> +int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
> +{
> + unsigned long inbits;
> + int rc, i, matches = 0, totct = 0;
> + char query[FMT_QUERY_SIZE];
> + const struct dyndbg_bitdesc *bitmap = kp->data;
> +
> +
On Fri, Mar 12, 2021 at 1:31 AM Boris Brezillon
wrote:
>
> On Thu, 11 Mar 2021 12:11:48 -0600
> Jason Ekstrand wrote:
>
> > > > > > > 2/ Queued jobs might be executed out-of-order (unless they have
> > > > > > > explicit/implicit deps
pread/pwrite ioctl's for future platforms (v3)
Jason Ekstrand (2):
drm/i915/gem: Drop legacy execbuffer support (v2)
drm/i915/gem: Drop relocation support on all new hardware (v5)
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 113 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.
.
v2 (Jason Ekstrand):
- Add a comment saying what Linux version it's being removed in.
Signed-off-by: Jason Ekstrand
Acked-by: Keith Packard
Acked-by: Dave Airlie
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
all memory is
directly CPU-accessible carries significant advantages.
v2 (Jason Ekstrand):
- Allow TGL-LP platforms as they've already shipped
v3 (Jason Ekstrand):
- WARN_ON platforms with LMEM support in case the check is wrong
v4 (Jason Ekstrand):
- Call out Rocket Lake in the commit message
e and they're easily removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
7
Cc: Christian König
Cc: Michel Dänzer
Cc: Dave Airlie
Cc: Bas Nieuwenhuizen
Cc: Daniel Stone
Christian König (2):
dma-buf: add dma_fence_array_for_each (v2)
dma-buf: add dma_resv_get_singleton (v2)
Jason Ekstrand (1):
dma-buf: Add an API for exporting sync files (v6)
drivers/dma-buf/
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
From: Christian König
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for
e export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences i
On Wed, Sep 30, 2020 at 4:55 AM Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > > Explicit synchronization is the future. At least, that seems to be what
> > > most use
On Mon, Mar 15, 2021 at 4:05 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland. The client -
I-G-T tests:
https://lists.freedesktop.org/archives/igt-dev/2021-March/029825.html
On Mon, Mar 15, 2021 at 4:04 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implici
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
one
Christian König (2):
dma-buf: add dma_fence_array_for_each (v2)
dma-buf: add dma_resv_get_singleton (v2)
Jason Ekstrand (1):
dma-buf: Add an API for exporting sync files (v6)
drivers/dma-buf/dma-buf.c | 55 ++
drivers/dma-buf/dma-fe
e export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences i
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the
On Tue, Mar 16, 2021 at 3:51 AM Michel Dänzer wrote:
>
> On 2021-03-16 12:10 a.m., Jason Ekstrand wrote:
> > On Mon, Mar 15, 2021 at 4:05 PM Jason Ekstrand wrote:
> >>
> >> Modern userspace APIs like Vulkan are built on an explicit
> >> synchronization
all memory is
directly CPU-accessible carries significant advantages.
v2 (Jason Ekstrand):
- Allow TGL-LP platforms as they've already shipped
v3 (Jason Ekstrand):
- WARN_ON platforms with LMEM support in case the check is wrong
v4 (Jason Ekstrand):
- Call out Rocket Lake in the commit message
I should probably have said that the reviews are on v5 and it's very
different in v6 so they should probably be considered dropped until
re-confirmed.
On Wed, Mar 17, 2021 at 9:39 AM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>
7
IGT tests: https://lists.freedesktop.org/archives/igt-dev/2021-March/029825.html
Cc: Christian König
Cc: Michel Dänzer
Cc: Dave Airlie
Cc: Bas Nieuwenhuizen
Cc: Daniel Stone
Christian König (2):
dma-buf: add dma_fence_array_for_each (v2)
dma-buf: add dma_resv_get_singleton (v2)
Jason Eks
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the
e export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences i
in i915
in the first place.
Test-with: 20210121083742.46592-1-ashutosh.di...@intel.com
Cc: Daniel Vetter
Cc: Dave Airlie
Ashutosh Dixit (1):
drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
Jason Ekstrand (4):
drm/i915/gem: Drop legacy execbuffer support (v2)
drm
.
v2 (Jason Ekstrand):
- Add a comment saying what Linux version it's being removed in.
Signed-off-by: Jason Ekstrand
Acked-by: Keith Packard
Acked-by: Dave Airlie
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
all memory is
directly CPU-accessible carries significant advantages.
v2 (Jason Ekstrand):
- Allow TGL-LP platforms as they've already shipped
v3 (Jason Ekstrand):
- WARN_ON platforms with LMEM support in case the check is wrong
v4 (Jason Ekstrand):
- Call out Rocket Lake in the commit message
e and they're easily removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 217 +---
include/uapi/drm/
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 94 ++-
drivers/gpu/drm/i915
On March 18, 2021 08:13:41 Daniel Vetter wrote:
On Thu, Mar 18, 2021 at 10:38:11AM +0100, Christian König wrote:
Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from
-with: 20210319223233.2982842-1-ja...@jlekstrand.net
Jason Ekstrand (4):
drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
drm/i915: Drop the CONTEXT_CLONE API
drm/i915: Implement SINGLE_TIMELINE with a syncobj
drivers/gpu/drm/i915/Mak
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 112 ++
drivers/gpu/drm
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions
t, together with deleting
the CLONE_CONTEXT API, we should now have a 1:1 mapping between
intel_context and intel_timeline which should make some of our locking
mess a bit easier.
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/
On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand wrote:
>
> This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
> has never been used by any real userspace.
After further digging, there is a compute-runtime PR for this. I
still think we should drop it and I'
On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld
wrote:
>
> On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand wrote:
> >
> > On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand wrote:
> > >
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
&
On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula wrote:
>
> On Sat, 20 Mar 2021, Jason Ekstrand wrote:
> > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
>
> Small nit, I think it would be useful to reference commits with the
> citation style:
>
&
On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
wrote:
>
>
> On 19/03/2021 22:38, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that us
gt;>> On Mon, Mar 22, 2021 at 11:22:01AM +0000, Tvrtko Ursulin wrote:
> >>>>
> >>>> On 19/03/2021 22:38, Jason Ekstrand wrote:
> >>>>> This API allows one context to grab bits out of another context upon
> >>>>> creation. It can
On Mon, Mar 22, 2021 at 11:59 AM Daniel Vetter wrote:
>
> On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> >
o have gup_huge_pmd even if we can't operate on ptes.
> + */
Why move this comment? I think it was correct where it was
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t; means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-devel@lists.freedesktop.org
tructions.
Unfortunately I have no idea what the long ago special case of
allowing COW'd IO mappings is. :\
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ls idea of
> vma_is_cow_mapping() is better since it won't clash and cause compilation
> failures...
Well, lets update more mmap fops to use this new helper then?
Searching for VM_SHARED gives a good list, there are several in
drivers/infiniband
Jason
___
through TTM (like the patch from Felix a couple of weeks ago). If a driver
> can promise not to do that, then we can safely remove the lookup.
Isn't the devmap PTE flag arch optional? Does this fall back to not
using huge pages on arches that don't support it?
Also, I fee
On Tue, Mar 23, 2021 at 4:35 AM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 16:10, Jason Ekstrand wrote:
> > On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
>
> [snip]
>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>>
>>>>>>
> >>>>>> On 22/03/2021 14:09, Daniel Vetter wrote:
> >>>>>>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> >>>>>>>>
> >>>>>>>> On 19/03/2021 22:
eline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline whic
t get randconfig failures when the next patch creates
a link time dependency related to the use of MDEV_TYPE.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb
The kobj here is a type-erased version of mdev_type, which is already
stored in the struct mdev_device being passed in. It was only ever used to
compute the type_group_id, which is now extracted directly from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2
but if it is ever needed it would be
hard to add in retroactively, so do it now.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c | 15 +--
drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
dr
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c
y we can now understand how to directly fix the
obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type,
which is linked to the supported_types_list provided by the driver, and
thus the core code can directly return the array indexes all the drivers
actually want.
Jason
On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote:
>
> Side note: I feel like we could have better lines of communication
> between kernel devs and user-space devs. The new uAPI requirements seem
> to be a high barrier to entry for kernel devs. However sometimes
> user-space devs might be intereste
Adding mesa-dev and wayland-devel for broader circulation.
On Wed, Mar 17, 2021 at 5:19 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used
file have gitlab issue
> > associated and the number-id is also here in the todo file?
>
> Yeah that sounds reasonable. tbh we haven't started any of the
> intel-internal planning on most of these (ttm and scheduler are started),
> so none of these tracking things exist ye
r an ioctl [1], if you aren't familiar with
> that. I think just some basic stuff (description, which parameters are
> in/out, what the flags are) would be great.
Good call. v9 will have docs.
--Jason
___
dri-devel mailing li
On Tue, Mar 23, 2021 at 08:26:30PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote:
> > Ideally all of this would be moved to kvmgt.c, but it is entangled with
> > the rest of the "generic" code in an odd way. Thus put in
On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> >
> > On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas
On Wed, Mar 24, 2021 at 01:35:17PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 1:24 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
>
e somehow by
> adjusting it and moving it into the kerneldoc for the new follow_pte()
> function.
>
> Cc: 3...@google.com
> Cc: Jann Horn
> Cc: Paolo Bonzini
> Cc: Jason Gunthorpe
> Cc: Cornelia Huck
> Cc: Peter Xu
> Cc: Alex Williamson
> Cc: linux...@kv
vmf how big a page it can stuff in, not the vm
telling the driver to stuff in a certain size page which it might not
want to do.
Some devices want to work on a in-between page size like 64k so they
can't form 2M pages but they can stuff 64k of 4K pages in a batch on
every fault.
That i
Never used by Mesa AFAIK
Acked-by: Jason Ekstrand
On Tue, Mar 23, 2021 at 10:51 AM Maarten Lankhorst
wrote:
>
> Userptr should not need the kernel for a userspace memcpy, userspace
> needs to call memcpy directly.
>
> Specifically, disable i915_gem_pwrite_ioctl() and i915_
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 2:48 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:
> >
> > > > In an ideal world the creation/destruction of page
On Wed, Mar 24, 2021 at 6:36 AM Tvrtko Ursulin
wrote:
>
>
> On 24/03/2021 09:52, Daniel Vetter wrote:
> > On Wed, Mar 24, 2021 at 09:28:58AM +, Tvrtko Ursulin wrote:
> >>
> >> On 23/03/2021 17:51, Jason Ekstrand wrote:
> >>> This API is entirely u
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 7:31 PM, Christian König wrote:
> >
> >
> > Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
> > > On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel)
> &
Acked-by: Jason Ekstrand
On March 24, 2021 16:10:48 Daniel Vetter wrote:
Motivated by the pre-review process for i915 gem/gt features, but
probably useful in general for complex stuff.
v2: Add reminder to not forget userspace projects in the discussion
(Simon, Jason)
Cc: Simon Ser
Cc
m in this respect? Using the interface to fault in a 1G range in the hope
> it could map it to a huge pud may unexpectedly consume and populate some 16+
> MB of page tables.
If the underlying device block size is so big then sure, why not? The
"unexpectedly" should be quite rare/non
try sizes
> anyway, although I think in most cases a standard helper for this can be
> supplied.
Of course the driver needs some way to influence the VA mmap uses,
gernally it should align to the natural page size of the device
Jason
___
dri-dev
On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
> Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
> >
> > > Nope. The point here was that in this case, to make sure mmap uses the
On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
>
>
> Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
> > > Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
> > > > On Thu, Mar
On Thu, Mar 25, 2021 at 02:26:50PM +0100, Christian König wrote:
> Am 25.03.21 um 14:17 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
> > >
> > > Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
> > > > O
ze for this. Just looking at the size
> of the mapping should be enough.
Well, kind of, at a certain point we start to over-align things which
is a bit harmful too, it is best to cap it at what the device could
actually use, IMHO.
Keep in mind address space is not free, and 32 bit in particu
om what I can tell, reading of a 64-bit pmd_t on 32-bit
> PAE is not atomic, so in theory a huge pmd could be modified while reading
> the pmd_t making the dwords inconsistent How does that work with fast
> gup anyway?
It loops to get an atomic 64 bit value if the arch can't provide an
atomic 64 bit load
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
> > On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/24/21 9:25 PM, Dave Hansen wrote:
> > > > On 3/24/21
On Thu, Mar 25, 2021 at 4:21 PM Matthew Brost wrote:
>
> On Tue, Mar 23, 2021 at 12:51:49PM -0500, Jason Ekstrand wrote:
> > This API is entirely unnecessary and I'd love to get rid of it. If
> > userspace wants a single timeline across multiple contexts, they can
eline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline whic
On Fri, Mar 26, 2021 at 10:08:09AM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/25/21 7:24 PM, Jason Gunthorpe wrote:
> > On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
> > > > On Thu,
h later patches will then
> roll out to all appropriate places.
>
> Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to use
> that by drivers/modules is together with an mmu_notifier, and that's
> all _GPL stuff.
>
> Signed-off-by: Daniel Vetter
> Cc: Christop
g the pte somehow by
> adjusting it and moving it into the kerneldoc for the new follow_pte()
> function.
>
> Cc: 3...@google.com
> Cc: Jann Horn
> Cc: Paolo Bonzini
> Cc: Jason Gunthorpe
> Cc: Cornelia Huck
> Cc: Peter Xu
> Cc: Alex Williamson
> Cc: linux...@kv
> mm/memory.c | 10 +++---
> mm/migrate.c| 6 ++--
> mm/page_vma_mapped.c| 6 ++--
> 10 files changed, 50 insertions(+), 81 deletions(-)
Looks good
Reviewed-by: Jason Gunthorpe
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 943cb2ba4442..3b2dda71d0ed
ed. The page will be
* returned with PG_mlocked cleared if no other vmas have it mlocked.
*/
So what clears PG_mlocked on this call path?
Something needs attention here..
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
}
This needs to have the same logic as we now have in
copy_present_page(). The page *is* present and we can't copy the PTE
value hidden in a swap entry if we can't copy the PTE normally.
The code should be shared because nobody is going to remember about
this corner case.
Jas
rrect, but perhaps the naming could be better. Would be
> interested hearing any thoughts on renaming try_to_munlock() to
> try_to_mlock()
> as the current name appears based on the context it is called from (munlock)
> rather than what it does (mlock).
The point of this patch is to ma
under the
page table locks of a single VMA?
- Why do we need to check for huge pages inside the VMA loop, not
before going to the rmap? PageTransCompoundHead() is not sensitive to
the PTEs. (and what happens if the huge page breaks up concurrently?)
- Why do we clear the mlock bit then run around to try and set it?
Feels racey.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ings? If I
pin it before you migrate it then it remains pinned but hidden under
the swap entry?
So the special logic is needed and the pinned page has to be copied
and written as a normal pte, not dropped as a migration entry
Jason
___
dri-devel mailing
On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> >
> > > I guess that makes sense as the split could go either way a
On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
>
On Thu, Apr 01, 2021 at 01:20:05PM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 11:48:13 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
>
ma-buf based MR registration
> RDMA/mlx5: Support dma-buf based userspace memory region
I applied the below fix for rereg, but otherwise took this to rdma's
for-next
Thanks,
Jason
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index f9ca19fa531b45..a63ef7c66e38
needs to be extended to take drm/* files too :(.
>
> drm kernel headers are in the libdrm package. You need that anyway for
> doing the ioctls (if you don't hand-roll the restarting yourself).
>
> Also our userspace has gone over to just outright copying the driver
> headers. Not the generic headers, but for the rendering side of gpus,
> which is the topic here, there's really not much generic stuff.
>
> > Jianxin, are you fixing it?
>
> So fix is either to depend upon libdrm for building, or have copies of
> the headers included in the package for the i915/amdgpu/radeon headers
> (drm/drm.h probably not so good idea).
We should have a cmake test to not build the drm parts if it can't be
built, and pyverbs should skip the tests.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ibnl for similar reasons, I just don't
like it to see it used gratuitously as it can cause more problems than
it solves
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
301 - 400 of 3569 matches
Mail list logo
