lkml.org 
[lkml]   [2017]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject__mutex_lock_common() unlikely very likely
Chris,

My branch tracer flagged the unlikely in __mutex_lock_common() as
always hit. That's the:

if (use_ww_ctx) {
[...]
if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
return -EALREADY;
}

This is hit 100% of the time, and its coming from the drm logic:

for example:

<stack trace>
=> drm_atomic_get_crtc_state
=> drm_atomic_helper_duplicate_state
=> intel_modeset_init
=> i915_driver_load
=> i915_pci_probe
=> local_pci_probe
=> pci_device_probe
=> driver_probe_device
=> __driver_attach
=> bus_for_each_dev
=> driver_attach
=> bus_add_driver
=> driver_register
=> __pci_register_driver
=> ext4_has_free_clusters
=> do_one_initcall
=> do_init_module
=> load_module
=> SYSC_init_module
=> SyS_init_module
=> entry_SYSCALL_64_fastpath

This is happening on 3 boxes of mine running normal loads (servers,
email, facebook, etc).

Commit 0422e83d84ae2 says:

Recursive locking for ww_mutexes was originally conceived as an
exception. However, it is heavily used by the DRM atomic modesetting
code. Currently, the recursive deadlock is checked after we have queued
up for a busy-spin and as we never release the lock, we spin until
kicked, whereupon the deadlock is discovered and reported.

Should this be converted to a likely?

-- Steve

\
 
 \ /
  Last update: 2017-01-18 22:08    [W:0.114 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site