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. > > In both cases, we will zero out nr_in_batch in the shrinker structure to > notify other shrinkers that we are the ones shrinking. > > -- > 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> -- 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>