Thread (43 messages) 43 messages, 3 authors, 2021-01-14

Re: [v3 PATCH 05/11] mm: vmscan: use a new flag to indicate shrinker is registered

From: Yang Shi <hidden>
Date: 2021-01-12 21:43:42
Also in: linux-mm, lkml

On Mon, Jan 11, 2021 at 1:38 PM Kirill Tkhai [off-list ref] wrote:
On 11.01.2021 21:17, Yang Shi wrote:
quoted
On Wed, Jan 6, 2021 at 2:22 AM Kirill Tkhai [off-list ref] wrote:
quoted
On 06.01.2021 01:58, Yang Shi wrote:
quoted
Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred.
This approach is fine with nr_deferred at the shrinker level, but the following
patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so their
shrinker->nr_deferred would always be NULL.  This would prevent the shrinkers
from unregistering correctly.

Signed-off-by: Yang Shi <redacted>
---
 include/linux/shrinker.h |  7 ++++---
 mm/vmscan.c              | 13 +++++++++----
 2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 0f80123650e2..1eac79ce57d4 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -79,13 +79,14 @@ struct shrinker {
 #define DEFAULT_SEEKS 2 /* A good number if you don't know better. */

 /* Flags */
-#define SHRINKER_NUMA_AWARE  (1 << 0)
-#define SHRINKER_MEMCG_AWARE (1 << 1)
+#define SHRINKER_REGISTERED  (1 << 0)
+#define SHRINKER_NUMA_AWARE  (1 << 1)
+#define SHRINKER_MEMCG_AWARE (1 << 2)
 /*
  * It just makes sense when the shrinker is also MEMCG_AWARE for now,
  * non-MEMCG_AWARE shrinker should not have this flag set.
  */
-#define SHRINKER_NONSLAB     (1 << 2)
+#define SHRINKER_NONSLAB     (1 << 3)

 extern int prealloc_shrinker(struct shrinker *shrinker);
 extern void register_shrinker_prepared(struct shrinker *shrinker);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8da765a85569..9761c7c27412 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -494,6 +494,7 @@ void register_shrinker_prepared(struct shrinker *shrinker)
      if (shrinker->flags & SHRINKER_MEMCG_AWARE)
              idr_replace(&shrinker_idr, shrinker, shrinker->id);
 #endif
+     shrinker->flags |= SHRINKER_REGISTERED;
In case of we introduce this new flag, we should kill old flag SHRINKER_REGISTERING,
which are not needed anymore (we should you the new flag instead of that).
The only think that I'm confused with is the check in
shrink_slab_memcg, it does:

shrinker = idr_find(&shrinker_idr, i);
if (unlikely(!shrinker || shrinker == SHRINKER_REGISTERING)) {

When allocating idr, the shrinker is associated with
SHRINKER_REGISTERING. But, shrink_slab_memcg does acquire read
shrinker_rwsem, and idr_alloc is called with holding write
shrinker_rwsem, so I'm supposed shrink_slab_memcg should never see
shrinker is registering.
After prealloc_shrinker() shrinker is visible for shrink_slab_memcg().
This is the moment shrink_slab_memcg() sees SHRINKER_REGISTERED.
Yes, this exactly is what I'm supposed.
quoted
If so it seems easy to remove
SHRINKER_REGISTERING.

We just need change that check to:
!shrinker || !(shrinker->flags & SHRINKER_REGISTERED)
quoted
quoted
      up_write(&shrinker_rwsem);
 }
@@ -513,13 +514,17 @@ EXPORT_SYMBOL(register_shrinker);
  */
 void unregister_shrinker(struct shrinker *shrinker)
 {
-     if (!shrinker->nr_deferred)
-             return;
-     if (shrinker->flags & SHRINKER_MEMCG_AWARE)
-             unregister_memcg_shrinker(shrinker);
      down_write(&shrinker_rwsem);
I do not think there are some users which registration may race with unregistration.
So, I think we should check SHRINKER_REGISTERED unlocked similar to we used to check
shrinker->nr_deferred unlocked.
Yes, I agree.
quoted
quoted
+     if (!(shrinker->flags & SHRINKER_REGISTERED)) {
+             up_write(&shrinker_rwsem);
+             return;
+     }
      list_del(&shrinker->list);
+     shrinker->flags &= ~SHRINKER_REGISTERED;
      up_write(&shrinker_rwsem);
+
+     if (shrinker->flags & SHRINKER_MEMCG_AWARE)
+             unregister_memcg_shrinker(shrinker);
      kfree(shrinker->nr_deferred);
      shrinker->nr_deferred = NULL;
 }
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help