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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
