On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs <[email protected]> wrote: > On 11/09/2015 05:37 PM, Alexandre Courbot wrote: >> The LRU list used for recycling CPU mappings was handling concurrency >> very poorly. For instance, if an instobj was acquired twice before being >> released once, it would end up into the LRU list even though there is >> still a client accessing it. >> >> This patch fixes this by properly counting how many clients are >> currently using a given instobj. > Out of curiosity, which instobjs are being accessed concurrently?
PGTs it seems - at least this is what dumping a stack when detecting a concurrent usage on an instobj indicates: [ 270.547052] [<bf0618dc>] (gk20a_instobj_acquire [nouveau]) from [<bf066358>] (gf100_vm_map_sg+0x58/0x124 [nouveau]) [ 270.557568] [<bf066358>] (gf100_vm_map_sg [nouveau]) from [<bf0641b0>] (nvkm_vm_map+0x300/0x3bc [nouveau]) [ 270.567333] [<bf0641b0>] (nvkm_vm_map [nouveau]) from [<bf0bcbd4>] (nouveau_bo_vma_add+0x74/0xa0 [nouveau]) [ 270.577189] [<bf0bcbd4>] (nouveau_bo_vma_add [nouveau]) from [<bf0bdbd0>] (nouveau_gem_object_open+0x124/0x158 [nouveau]) [ 270.588196] [<bf0bdbd0>] (nouveau_gem_object_open [nouveau]) from [<c02da62c>] (drm_gem_handle_create_tail+0x104/0x19c) [ 270.599025] [<c02da62c>] (drm_gem_handle_create_tail) from [<bf0be138>] (nouveau_gem_ioctl_new+0x90/0x18c [nouveau]) [ 270.609594] [<bf0be138>] (nouveau_gem_ioctl_new [nouveau]) from [<c02db3b8>] (drm_ioctl+0x284/0x440) [ 270.618777] [<c02db3b8>] (drm_ioctl) from [<bf0b6bfc>] (nouveau_drm_ioctl+0x54/0x98 [nouveau]) [ 270.627441] [<bf0b6bfc>] (nouveau_drm_ioctl [nouveau]) from [<c0103860>] (do_vfs_ioctl+0x458/0x6dc) [ 270.636471] [<c0103860>] (do_vfs_ioctl) from [<c0103b18>] (SyS_ioctl+0x34/0x5c) [ 270.643767] [<c0103b18>] (SyS_ioctl) from [<c000f5c0>] (ret_fast_syscall+0x0/0x3c) _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
