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@xxxxxxxxx> I asked to remove the comment of zs_can_compact about lock. "Should be called under class->lock." Otherwise, Acked-by: Minchan Kim <minchan@xxxxxxxxxx> > --- > 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, 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>