On Wed, Apr 10, 2013 at 01:09:42PM +0800, Ric Mason wrote: > Hi Glauber, > On 04/01/2013 04:10 PM, Glauber Costa wrote: > > Hi Kame, > > > >> Doesn't this break > >> > >> == > >> /* > >> * copy the current shrinker scan count into a local variable > >> * and zero it so that other concurrent shrinker invocations > >> * don't also do this scanning work. > >> */ > >> nr = atomic_long_xchg(&shrinker->nr_in_batch, 0); > >> == > >> > >> This xchg magic ? > >> > >> Thnks, > >> -Kame > > This is done before the actual reclaim attempt, and all it does is to > > indicate to other concurrent shrinkers that "I've got it", and others > > should not attempt to shrink. > > > > Even before I touch this, this quantity represents the number of > > entities we will try to shrink. Not necessarily we will succeed. What my > > patch does, is to try at least once if the number is too small. > > > > Before it, we will try to shrink 512 objects and succeed at 0 (because > > batch is 1024). After this, we will try to free 512 objects and succeed > > at an undefined quantity between 0 and 512. > > Where you get the magic number 512 and 1024? The value of SHRINK_BATCH > is 128. The default is SHRINK_BATCH, but batch size has been customisable for some time now... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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>