On Thu, Feb 21, 2019 at 02:46:17PM -0800, Roman Gushchin wrote: > On Wed, Feb 20, 2019 at 06:27:07PM +1100, Dave Chinner wrote: > > On Wed, Feb 20, 2019 at 04:50:31PM +1100, Dave Chinner wrote: > > > I'm just going to fix the original regression in the shrinker > > > algorithm by restoring the gradual accumulation behaviour, and this > > > whole series of problems can be put to bed. > > > > Something like this lightly smoke tested patch below. It may be > > slightly more agressive than the original code for really small > > freeable values (i.e. < 100) but otherwise should be roughly > > equivalent to historic accumulation behaviour. > > > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > david@xxxxxxxxxxxxx > > > > mm: fix shrinker scan accumulation regression > > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > JFYI: I'm testing this patch in our environment for fixing > the memcg memory leak. > > It will take a couple of days to get reliable results. > So unfortunately the proposed patch is not solving the dying memcg reclaim issue. I've tested it as is, with s/ilog2()/fls(), suggested by Johannes, and also with more a aggressive zero-seek slabs reclaim (always scanning at least SHRINK_BATCH for zero-seeks shrinkers). In all cases the number of outstanding memory cgroups grew almost linearly with time and didn't show any signs of plateauing. Thanks!
