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 <[email protected]>
I asked to remove the comment of zs_can_compact about lock. "Should be called under class->lock." Otherwise, Acked-by: Minchan Kim <[email protected]> > --- > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
