The patch titled
Subject: mm/vmscan.c: terminate shrink_slab loop if signal is pending
has been removed from the -mm tree. Its filename was
mm-terminate-shrink_slab-loop-if-signal-is-pending.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Suren Baghdasaryan <surenb@xxxxxxxxxx>
Subject: mm/vmscan.c: terminate shrink_slab loop if signal is pending
Slab shrinkers can be quite time consuming and when signal is pending they
can delay handling of the signal. If fatal signal is pending there is no
point in shrinking that process since it will be killed anyway. This
change checks for pending fatal signals inside shrink_slab loop and if one
is detected terminates this loop early.
The observable delay depends on the implementation of the shrinkers
registered in the system including the ones from drivers. I've
captured traces showing delays of up to 100ms where the process with
pending SIGKILL is in direct memory reclaim and signal handling is
delayed because of that. I realize that it's not the fault of
shrink_slab() that some shrinkers take long time to shrink their slabs
(sometimes because of justifiable reasons and sometimes because of a
bug which has to be fixed) but this can be a safeguard against such
cases. Couple shrinker examples that I found most time consuming are
(most of that 100ms delay is the result of the first two ones):
https://patchwork.kernel.org/patch/10096641/: the patch fixes dm-bufio
shrinker which in certain conditions reclaims only one buffer per scan
making the shrinking process very inefficient.
https://android.googlesource.com/kernel/msm/+/android-7.1.0_r0.2/drivers/gpu/msm/kgsl_pool.c#420:
This example is from a driver where shrinker returns 0 instead of
SHRINK_STOP when it's unable to reclaim anymore. As a result when
total_scan in do_shrink_slab() is large this will cause multiple
scan_objects() calls with no memory being reclaimed. Patch for this
one is under review by the owners.
Shrinker that seems to be justifiably heavy is super_cache_scan()
inside fs/super.c. I have traces where it takes up to 4ms to complete.
[akpm@xxxxxxxxxxxxxxxxxxxx: fix build, per Sergey]
Link: http://lkml.kernel.org/r/20171206192026.25133-1-surenb@xxxxxxxxxx
Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Hillf Danton <hdanton@xxxxxxxx>
Cc: Minchan Kim <minchan@xxxxxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
Cc: Huang Ying <ying.huang@xxxxxxxxx>
Cc: Tim Murray <timmurray@xxxxxxxxxx>
Cc: Todd Kjos <tkjos@xxxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxx>
Cc: Pekka Enberg <penberg@xxxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/vmscan.c | 7 +++++++
1 file changed, 7 insertions(+)
diff -puN mm/vmscan.c~mm-terminate-shrink_slab-loop-if-signal-is-pending mm/vmscan.c
--- a/mm/vmscan.c~mm-terminate-shrink_slab-loop-if-signal-is-pending
+++ a/mm/vmscan.c
@@ -490,6 +490,13 @@ static unsigned long shrink_slab(gfp_t g
};
/*
+ * We are about to die and free our memory.
+ * Stop shrinking which might delay signal handling.
+ */
+ if (unlikely(fatal_signal_pending(current)))
+ break;
+
+ /*
* If kernel memory accounting is disabled, we ignore
* SHRINKER_MEMCG_AWARE flag and call all shrinkers
* passing NULL for memcg.
_
Patches currently in -mm which might be from surenb@xxxxxxxxxx are
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
