This case still able to reproduce on latest -nihgtly(79e44bfa10063ee529140e88fdc401c4ce07d644)

Case list:
igt/gem_userptr_blits/swapping-unsync-normal
igt/gem_userptr_blits/swapping-unsync-interruptible
igt/gem_userptr_blits/swapping-sync-interruptible
igt/gem_userptr_blits/swapping-normal-sync

It also happens on BSW.

5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06 is the first bad commit
Author:     Mika Kuoppala <mika.kuoppala@linux.intel.com>
AuthorDate: Fri May 16 13:44:12 2014 +0300
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Fri May 16 16:28:56 2014 +0200


    drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl

    By exporting the ability to map user address and inserting PTEs
    representing their backing pages into the GTT, we can exploit UMA in order
    to utilize normal application data as a texture source or even as a
    render target (depending upon the capabilities of the chipset). This has
    a number of uses, with zero-copy downloads to the GPU and efficient
    readback making the intermixed streaming of CPU and GPU operations
    fairly efficient. This ability has many widespread implications from
    faster rendering of client-side software rasterisers (chromium),
    mitigation of stalls due to read back (firefox) and to faster pipelining
    of texture data (such as pixel buffer objects in GL or data blobs in CL).

    v2: Compile with CONFIG_MMU_NOTIFIER
    v3: We can sleep while performing invalidate-range, which we can utilise
    to drop our page references prior to the kernel manipulating the vma
    (for either discard or cloning) and so protect normal users.
    v4: Only run the invalidate notifier if the range intercepts the bo.
    v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
    v6: Recheck after reacquire mutex for lost mmu.
    v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
    v8: Fix rebasing error after forwarding porting the back port.
    v9: Limit the userptr to page aligned entries. We now expect userspace
        to handle all the offset-in-page adjustments itself.
    v10: Prevent vma from being copied across fork to avoid issues with cow.
    v11: Drop vma behaviour changes -- locking is nigh on impossible.
         Use a worker to load user pages to avoid lock inversions.
    v12: Use get_task_mm()/mmput() for correct refcounting of mm.
    v13: Use a worker to release the mmu_notifier to avoid lock inversion
    v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
         with its own locking and tree of objects for each mm/mmu_notifier.
    v15: Prevent overlapping userptr objects, and invalidate all objects
         within the mmu_notifier range
    v16: Fix a typo for iterating over multiple objects in the range and
         rearrange error path to destroy the mmu_notifier locklessly.
         Also close a race between invalidate_range and the get_pages_worker.
    v17: Close a race between get_pages_worker/invalidate_range and fresh
         allocations of the same userptr range - and notice that
         struct_mutex was presumed to be held when during creation it wasn't.
    v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
         for the struct sg_table and to clear it before reporting an error.
    v19: Always error out on read-only userptr requests as we don't have the
         hardware infrastructure to support them at the moment.
    v20: Refuse to implement read-only support until we have the required
         infrastructure - but reserve the bit in flags for future use.
    v21: use_mm() is not required for get_user_pages(). It is only meant to
         be used to fix up the kernel thread's current->mm for use with
         copy_user().
    v22: Use sg_alloc_table_from_pages for that chunky feeling
    v23: Export a function for sanity checking dma-buf rather than encode
         userptr details elsewhere, and clean up comments based on
         suggestions by Bradley.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
    Cc: Akash Goel <akash.goel@intel.com>
    Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
    [danvet: Frob ioctl allocation to pick the next one - will cause a bit
    of fuss with create2 apparently, but such are the rules.]
    [danvet2: oops, forgot to git add after manual patch application]
    [danvet3: Appease sparse.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 7bb913fcb031477acbd3e9f994cbc24771c979fa c1f1ca986ce04f935817b3ae43f0266bec4dd289 M      drivers
:040000 040000 f41358f6ef0f41344941b899c1b53fa8a4fd6fd4 95df53cf81f5b5dda6af773a518cb3e8031b12b7 M      include

On first bad commit, the test result was killed instead timeout.

root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# time ./gem_userptr_blits --run-subtest swapping-normal-sync
IGT-Version: 1.7-gf473a55 (x86_64) (Linux: 3.15.0-rc3_kcloud_5cc9ed_20140902+ x86_64)
Aperture size is 4096 MiB
Total RAM is 3876 MiB
Testing unsynchronized mappings...
Testing synchronized mappings...
Killed

real    0m6.947s
user    0m0.016s
sys     0m5.438s

Uh, the test should be skipped before that commit since the infrastructure being tested doesn't exist. This bug is just the normal swap thrash tests are by definition slow.

Killed, not timeout. That's different and should be tracked separately. Probably just bug 80745.

The failure is able to reproduce on latest -fixes(bbfb44e8b688e778964275ab0862f67463ba4f84) on IVB

[root@x-ivb6 tests]# time ./gem_userptr_blits --run-subtest swapping-unsync-normal
IGT-Version: 1.7-gf473a55 (x86_64) (Linux: 3.17.0-rc2_drm-intel-fixes_bbfb44_20140903_debug+ x86_64)
Aperture size is 2048 MiB
Total RAM is 7868 MiB
Testing unsynchronized mappings...
^C



real    17m27.680s
user    0m0.664s
sys     14m13.133s

Test below unable to exit on HSW IVB

[root@x-hsw27 tests]# time ./gem_userptr_blits --run-subtest create-destroy-sync
IGT-Version: 1.8-g32a0308 (x86_64) (Linux: 3.17.0-rc6_drm-intel-fixes_c84db7_20140929+ x86_64)
Aperture size is 2048 MiB
Total RAM is 7669 MiB
Testing unsynchronized mappings...
Testing synchronized mappings...




^C

[root@x-ivb9 tests]# time ./gem_userptr_blits --run-subtest create-destroy-sync
IGT-Version: 1.8-g32a0308 (x86_64) (Linux: 3.17.0-rc6_drm-intel-nightly_7101d8_20140929+ x86_64)
Aperture size is 2048 MiB
Total RAM is 3836 MiB
Testing unsynchronized mappings...
Testing synchronized mappings...






^C^C

(In reply to comment #8)
> Test below unable to exit on HSW IVB
> 
> [root@x-hsw27 tests]# time ./gem_userptr_blits --run-subtest
> create-destroy-sync
> IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> 3.17.0-rc6_drm-intel-fixes_c84db7_20140929+ x86_64)
> Aperture size is 2048 MiB
> Total RAM is 7669 MiB
> Testing unsynchronized mappings...
> Testing synchronized mappings...
> 
> 
> 
> 
> ^C
> 
> [root@x-ivb9 tests]# time ./gem_userptr_blits --run-subtest
> create-destroy-sync
> IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> 3.17.0-rc6_drm-intel-nightly_7101d8_20140929+ x86_64)
> Aperture size is 2048 MiB
> Total RAM is 3836 MiB
> Testing unsynchronized mappings...
> Testing synchronized mappings...
> 
> 
> 
> 
> 
> 
> ^C^C

Right, that is a different bug, bug 84207 to be precise.

(In reply to comment #9)
> (In reply to comment #8)
> > Test below unable to exit on HSW IVB
> > 
> > [root@x-hsw27 tests]# time ./gem_userptr_blits --run-subtest
> > create-destroy-sync
> > IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> > 3.17.0-rc6_drm-intel-fixes_c84db7_20140929+ x86_64)
> > Aperture size is 2048 MiB
> > Total RAM is 7669 MiB
> > Testing unsynchronized mappings...
> > Testing synchronized mappings...
> > 
> > 
> > 
> > 
> > ^C
> > 
> > [root@x-ivb9 tests]# time ./gem_userptr_blits --run-subtest
> > create-destroy-sync
> > IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> > 3.17.0-rc6_drm-intel-nightly_7101d8_20140929+ x86_64)
> > Aperture size is 2048 MiB
> > Total RAM is 3836 MiB
> > Testing unsynchronized mappings...
> > Testing synchronized mappings...
> > 
> > 
> > 
> > 
> > 
> > 
> > ^C^C
> 
> Right, that is a different bug, bug 84207 to be precise.

Ok, I will update latest test result on bug 84207, thanks.

(In reply to Chris Wilson from comment #9)
> (In reply to comment #8)
> > Test below unable to exit on HSW IVB
> > 
> > [root@x-hsw27 tests]# time ./gem_userptr_blits --run-subtest
> > create-destroy-sync
> > IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> > 3.17.0-rc6_drm-intel-fixes_c84db7_20140929+ x86_64)
> > Aperture size is 2048 MiB
> > Total RAM is 7669 MiB
> > Testing unsynchronized mappings...
> > Testing synchronized mappings...
> > 
> > 
> > 
> > 
> > ^C
> > 
> > [root@x-ivb9 tests]# time ./gem_userptr_blits --run-subtest
> > create-destroy-sync
> > IGT-Version: 1.8-g32a0308 (x86_64) (Linux:
> > 3.17.0-rc6_drm-intel-nightly_7101d8_20140929+ x86_64)
> > Aperture size is 2048 MiB
> > Total RAM is 3836 MiB
> > Testing unsynchronized mappings...
> > Testing synchronized mappings...
> > 
> > 
> > 
> > 
> > 
> > 
> > ^C^C
> 
> Right, that is a different bug, bug 84207 to be precise.

This issue is not about "long time to execute", In fact, system hang, report bug 84853.

It also happens on SNB platform.

(In reply to lu hua from comment #11)
> This issue is not about "long time to execute", In fact, system hang, report
> bug 84853.

Since this hang is fixed now, can we close this one here as too?

(In reply to Daniel Vetter from comment #13)
> (In reply to lu hua from comment #11)
> > This issue is not about "long time to execute", In fact, system hang, report
> > bug 84853.
> 
> Since this hang is fixed now, can we close this one here as too?

Ping.

(In reply to Daniel Vetter from comment #13)
> (In reply to lu hua from comment #11)
> > This issue is not about "long time to execute", In fact, system hang, report
> > bug 84853.
> 
> Since this hang is fixed now, can we close this one here as too?

Isn't this the "swapping is slow" bug? It could be WONTFIX, I suppose.

Thomas Wood is working on the "swapping is slow" bug by mlocking most of memory. He's done a quick experiment and it speeds things up substantially.

(In reply to Daniel Vetter from comment #16)
> Thomas Wood is working on the "swapping is slow" bug by mlocking most of
> memory. He's done a quick experiment and it speeds things up substantially.

But I am not allowed to do the same with gfx driver memory! Double standards! :-p

Test passes on latest -nightly(0db9cf7742874ee2c09a35b640c1bb04cb379eb6)


[root@x-ivb9 tests]# time ./gem_userptr_blits --run-subtest swapping-normal-sync
IGT-Version: 1.8-gdbac905 (x86_64) (Linux: 3.18.0-rc6_drm-intel-nightly_0db9cf_20141130_debug+ x86_64)
Aperture size is 2048 MiB
Total RAM is 3821 MiB
Testing unsynchronized mappings...
Testing synchronized mappings...
Subtest swapping-normal-sync: SUCCESS (316.811s)

real    5m16.883s
user    0m0.225s
sys     3m21.150s

Closing verified+fixed.