Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1186718 > unrolled thread

[PATCH v2] zsmalloc: do not take class lock in zs_shrinker_count()

Back to article view | Back to linux.kernel

Contents

  [PATCH v2] zsmalloc: do not take class lock in zs_shrinker_count() Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2015-07-17 13:20 +0200
    Re: [PATCH v2] zsmalloc: do not take class lock in  zs_shrinker_count() Minchan Kim <minchan@kernel.org> - 2015-07-18 00:50 +0200

#1186718 — [PATCH v2] zsmalloc: do not take class lock in zs_shrinker_count()

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@gmail.com>
---
 mm/zsmalloc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 1edd8a0..ed64cf5 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1836,9 +1836,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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1187267 — Re: [PATCH v2] zsmalloc: do not take class lock in zs_shrinker_count()

Hi Sergey,

On Fri, Jul 17, 2015 at 08:18:18PM +0900, Sergey Senozhatsky wrote:
> 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@gmail.com>

I asked to remove the comment of zs_can_compact about lock.
"Should be called under class->lock."

Otherwise,

Acked-by: Minchan Kim <minchan@kernel.org>

> ---
>  mm/zsmalloc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 1edd8a0..ed64cf5 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1836,9 +1836,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
> 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web