We can avoid taking class ->lock around zs_can_compact() in
zs_shrinker_count(), because the number that we return back
is outdated in general case, by design. We have different
sources that are able to change class's state right after we
return from zs_can_compact() -- ongoing I/O operations, manually
triggered compaction, or two of them happening simultaneously.
We re-do this calculations during compaction on a per class basis
anyway.
zs_unregister_shrinker() will not return until we have an
active shrinker, so classes won't unexpectedly disappear
while zs_shrinker_count() iterates them.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx>
Acked-by: Minchan Kim <minchan@xxxxxxxxxx>
---
mm/zsmalloc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 1edd8a0..c1399e8 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1711,8 +1711,6 @@ static struct page *isolate_source_page(struct size_class *class)
*
* Based on the number of unused allocated objects calculate
* and return the number of pages that we can free.
- *
- * Should be called under class->lock.
*/
static unsigned long zs_can_compact(struct size_class *class)
{
@@ -1836,9 +1834,7 @@ static unsigned long zs_shrinker_count(struct shrinker *shrinker,
if (class->index != i)
continue;
- spin_lock(&class->lock);
pages_to_free += zs_can_compact(class);
- spin_unlock(&class->lock);
}
return pages_to_free;
--
2.4.6
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>