[Bug 80578] [All Regression]igt/gem_fence_upload/thread-contention costs long time to execute sporadically

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80578

Chris Wilson <chris at chris-wilson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 37e9562453b813d2ea527bd9531fef2c3c592847
Author: Jason Low <jason.low2 at hp.com>
Date:   Fri Jul 4 20:49:32 2014 -0700

    locking/rwsem: Allow conservative optimistic spinning when readers have
lock

    Commit 4fc828e24cd9 ("locking/rwsem: Support optimistic spinning")
    introduced a major performance regression for workloads such as
    xfs_repair which mix read and write locking of the mmap_sem across
    many threads. The result was xfs_repair ran 5x slower on 3.16-rc2
    than on 3.15 and using 20x more system CPU time.

    Perf profiles indicate in some workloads that significant time can
    be spent spinning on !owner. This is because we don't set the lock
    owner when readers(s) obtain the rwsem.

    In this patch, we'll modify rwsem_can_spin_on_owner() such that we'll
    return false if there is no lock owner. The rationale is that if we
    just entered the slowpath, yet there is no lock owner, then there is
    a possibility that a reader has the lock. To be conservative, we'll
    avoid spinning in these situations.

    This patch reduced the total run time of the xfs_repair workload from
    about 4 minutes 24 seconds down to approximately 1 minute 26 seconds,
    back to close to the same performance as on 3.15.

    Retesting of AIM7, which were some of the workloads used to test the
    original optimistic spinning code, confirmed that we still get big
    performance gains with optimistic spinning, even with this additional
    regression fix. Davidlohr found that while the 'custom' workload took
    a performance hit of ~-14% to throughput for >300 users with this
    additional patch, the overall gain with optimistic spinning is
    still ~+45%. The 'disk' workload even improved by ~+15% at >1000 users.

    Tested-by: Dave Chinner <dchinner at redhat.com>
    Acked-by: Davidlohr Bueso <davidlohr at hp.com>
    Signed-off-by: Jason Low <jason.low2 at hp.com>
    Signed-off-by: Peter Zijlstra <peterz at infradead.org>
    Cc: Tim Chen <tim.c.chen at linux.intel.com>
    Cc: Linus Torvalds <torvalds at linux-foundation.org>
    Link: http://lkml.kernel.org/r/1404532172.2572.30.camel@j-VirtualBox
    Signed-off-by: Ingo Molnar <mingo at kernel.org>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140722/6e4c951c/attachment-0001.html>