search for: unpinned

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

Hi, > It turns out that the bochs and vbox drivers automatically reserved and > unreserved the BO from within their pin and unpin functions. The other > drivers; ast, hibmc and mgag200; performed reservation explicitly. With the > GEM VRAM conversion, automatic BO reservation within pin and unpin functions > accidentally got lost. So for bochs and vbox, ttm_bo_validate() worked on

...(drm_gem_vram_pin); +/** + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region. + * @gbo: the GEM VRAM object + * @pl_flag: a bitmask of possible memory regions + * + * Pinning a buffer object ensures that it is not evicted from + * a memory region. A pinned buffer object has to be unpinned before + * it can be pinned to another region. + * + * This function pins a GEM VRAM object that has already been + * reserved. Use drm_gem_vram_pin() if possible. + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_gem_vram_pin_reserved(struct drm_gem_vram_obje...

...vn''t seen problems without PAE, not sure whenever thats just pure luck or whenever there is a bug in my PAE xenlinux kernel. To me it looks like a generic bug though. I''ve actually trapped into problems with unpin only: A process exits, somewhere in exit_mm() the page tables are unpinned, shortly thereafter the mappings are cleared. While doing so the kernel oopses in zap_pte_range(), on page table write access. Probably due to some stale tlb entry where the page is still tagged read-only. cheers, Gerd Index: linux-2.6.11/arch/xen/i386/mm/pgtable.c ============================...

...served() - Pins a GEM VRAM object in a region. > > + * @gbo: the GEM VRAM object > > + * @pl_flag: a bitmask of possible memory regions > > + * > > + * Pinning a buffer object ensures that it is not evicted from > > + * a memory region. A pinned buffer object has to be unpinned before > > + * it can be pinned to another region. > > + * > > + * This function pins a GEM VRAM object that has already been > > + * reserved. Use drm_gem_vram_pin() if possible. > > + * > > + * Returns: > > + * 0 on success, or > > + * a negative er...

...RAM object in a region. >>> + * @gbo: the GEM VRAM object >>> + * @pl_flag: a bitmask of possible memory regions >>> + * >>> + * Pinning a buffer object ensures that it is not evicted from >>> + * a memory region. A pinned buffer object has to be unpinned before >>> + * it can be pinned to another region. >>> + * >>> + * This function pins a GEM VRAM object that has already been >>> + * reserved. Use drm_gem_vram_pin() if possible. >>> + * >>> + * Returns: >>> + * 0 on success, or >&g...

...; + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region. > + * @gbo: the GEM VRAM object > + * @pl_flag: a bitmask of possible memory regions > + * > + * Pinning a buffer object ensures that it is not evicted from > + * a memory region. A pinned buffer object has to be unpinned before > + * it can be pinned to another region. > + * > + * This function pins a GEM VRAM object that has already been > + * reserved. Use drm_gem_vram_pin() if possible. > + * > + * Returns: > + * 0 on success, or > + * a negative error code otherwise. > + */ > +int...

...; + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region. > + * @gbo: the GEM VRAM object > + * @pl_flag: a bitmask of possible memory regions > + * > + * Pinning a buffer object ensures that it is not evicted from > + * a memory region. A pinned buffer object has to be unpinned before > + * it can be pinned to another region. > + * > + * This function pins a GEM VRAM object that has already been > + * reserved. Use drm_gem_vram_pin() if possible. > + * > + * Returns: > + * 0 on success, or > + * a negative error code otherwise. > + */ > +int...

...nout with vram all we need is: > > - pin framebuffers, which potentially moves the underlying bo into vram > > - unpin framebuffers (which is just accounting, we don't want to move the > > bo on every flip!) > > - if a pin doesn't find enough space, move one of the unpinned bo still > > resident in vram out > > For dumb buffers, I'd expect userspace to have a working set of only a > front and back buffer (plus maybe a third one). This working set has to > reside in VRAM for performance reasons; non-WS BOs from other userspace > programs don&...

...nout with vram all we need is: > > - pin framebuffers, which potentially moves the underlying bo into vram > > - unpin framebuffers (which is just accounting, we don't want to move the > > bo on every flip!) > > - if a pin doesn't find enough space, move one of the unpinned bo still > > resident in vram out > > For dumb buffers, I'd expect userspace to have a working set of only a > front and back buffer (plus maybe a third one). This working set has to > reside in VRAM for performance reasons; non-WS BOs from other userspace > programs don&...

...t; >>> - pin framebuffers, which potentially moves the underlying bo into vram > >>> - unpin framebuffers (which is just accounting, we don't want to move the > >>> bo on every flip!) > >>> - if a pin doesn't find enough space, move one of the unpinned bo still > >>> resident in vram out > >> For dumb buffers, I'd expect userspace to have a working set of only a > >> front and back buffer (plus maybe a third one). This working set has to > >> reside in VRAM for performance reasons; non-WS BOs from oth...

-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jeremy Fitzhardinge <jeremy@goop.org> patch 9f79991d4186089e228274196413572cc000143b in mainline. When a pagetable is no longer in use, it must be unpinned so that its pages can be freed. However, this is only possible if there are no stray uses of the pagetable. The code currently deals with all the usual cases, but there's a rare case where a vcpu is changing cr3, but is doing so lazily, and the change hasn't actually happened by the time...

-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jeremy Fitzhardinge <jeremy@goop.org> patch 9f79991d4186089e228274196413572cc000143b in mainline. When a pagetable is no longer in use, it must be unpinned so that its pages can be freed. However, this is only possible if there are no stray uses of the pagetable. The code currently deals with all the usual cases, but there's a rare case where a vcpu is changing cr3, but is doing so lazily, and the change hasn't actually happened by the time...

The patched attached enables x86_64 xenlinux with "late pin, early unpin", which is already implemented for x86_32. Since we now only pin the root rather than any of the other levels, the overall performance became better especially with workloads that require heavy memory management operations. On 8-way x86_64 xenlinux (dom0) the kernel build was improved by about 10% (using make

This will otherwise cause a lockdep splat if reservations were a real lock type, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index cc79c79..acc6b08 100644 ---

This will otherwise cause a lockdep splat, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_prime.c |

When operating on an unpinned pagetable (ie, one under construction or destruction), it isn''t necessary to use a hypercall to update a pud/pmd entry. Jan Beulich observed that a similar optimisation avoided many thousands of hypercalls while doing a kernel build. One tricky part is that early in the kernel boot there...

virtio-gpu objects never move around, so effectively they are pinned all the time. This makes the the implementation pretty easy ;) Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index

Hi, > I think would be good to have a lockdep_assert_held here for the ww_mutex. > > Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations > we call the structure tracking the fences+lock the "reservation", but the > naming scheme used is _lock/_unlock. > > I think would be good to be consistent with that, and use _locked here. > Especially