FAILED: patch "[PATCH] drm/i915: Do not sync RCU during shrinking" failed to apply to 4.11-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 4.11-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
4681ee21d62cfed4364e09ec50ee8e88185dd628Mon Sep 17 00:00:00 2001
From: Joonas Lahtinen <[email protected]>
Date: Thu, 18 May 2017 11:49:39 +0300
Subject: [PATCH] drm/i915: Do not sync RCU during shrinking
Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking.
On low-on-memory systems (mem=1G for example), the RCU sync leads to all system workqueus freezing and unrelated lockdep splats are displayed according to reports. GIT bisecting done by J. R. Okajima points to the commit where RCU syncing was extended.
RCU sync gains us very little benefit in real life scenarios where the amount of memory used by object backing storage is dominant over the metadata under RCU, so drop it altogether.
" Yeeeaah, if core could just, go ahead and reclaim RCU
queues, that'd be great. "
- Chris Wilson, 2016 (0eafec6d3244)
v2: More information to commit message.
v3: Remove "grep _rcu_" escapee from i915_gem_shrink_all (Andrea)
drivers/gpu/drm/i915/i915_gem_shrinker.c +0 -5
@@ -59,9 +59,6 @@ static void i915_gem_shrinker_unlock(struct drm_device *dev, bool unlock)return ;mutex_unlock (&dev->struct_mutex); - -/* expedite the RCU grace period to free some request slabs */ -synchronize_rcu_expedited (); }static bool any_vma_pinned (struct drm_i915_gem_object *obj)
@@ -274,8 +271,6 @@ unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv) I915_SHRINK_ACTIVE);intel_runtime_pm_put (dev_priv); -synchronize_rcu ();/* wait for our earlier RCU delayed slab frees */ -return freed; }
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
4681ee21d62cfed4364e09ec50ee8e88185dd628Mon Sep 17 00:00:00 2001
From: Joonas Lahtinen <[email protected]>
Date: Thu, 18 May 2017 11:49:39 +0300
Subject: [PATCH] drm/i915: Do not sync RCU during shrinking
Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking.
On low-on-memory systems (mem=1G for example), the RCU sync leads to all system workqueus freezing and unrelated lockdep splats are displayed according to reports. GIT bisecting done by J. R. Okajima points to the commit where RCU syncing was extended.
RCU sync gains us very little benefit in real life scenarios where the amount of memory used by object backing storage is dominant over the metadata under RCU, so drop it altogether.
" Yeeeaah, if core could just, go ahead and reclaim RCU
queues, that'd be great. "
- Chris Wilson, 2016 (0eafec6d3244)
v2: More information to commit message.
v3: Remove "grep _rcu_" escapee from i915_gem_shrink_all (Andrea)
drivers/gpu/drm/i915/i915_gem_shrinker.c +0 -5
@@ -59,9 +59,6 @@ static void i915_gem_shrinker_unlock(strreturn ;mutex_unlock (&dev->struct_mutex); - -/* expedite the RCU grace period to free some request slabs */ -synchronize_rcu_expedited (); }static bool any_vma_pinned (struct drm_i915_gem_object *obj)
@@ -271,8 +268,6 @@ unsigned long i915_gem_shrink_all(structI915_SHRINK_BOUND |I915_SHRINK_UNBOUND | I915_SHRINK_ACTIVE); -synchronize_rcu ();/* wait for our earlier RCU delayed slab frees */ -return freed; }
Greg KH
maintainerQuoted 6 lines · Hugh Dickins
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
4681ee21d62cfed4364e09ec50ee8e88185dd628Mon Sep 17 00:00:00 2001From: Joonas Lahtinen <[email protected]>
Date: Thu, 18 May 2017 11:49:39 +0300
Subject: [PATCH] drm/i915: Do not sync RCU during shrinking
Many thanks for this, now applied.
greg k-h