On Wed, Nov 8, 2017 at 4:07 PM, Minchan Kim <minchan@xxxxxxxxxx> wrote: > Hi, > > On Wed, Nov 08, 2017 at 09:37:40AM -0800, Shakeel Butt wrote: >> In our production, we have observed that the job loader gets stuck for >> 10s of seconds while doing mount operation. It turns out that it was >> stuck in register_shrinker() and some unrelated job was under memory >> pressure and spending time in shrink_slab(). Our machines have a lot >> of shrinkers registered and jobs under memory pressure has to traverse >> all of those memcg-aware shrinkers and do affect unrelated jobs which >> want to register their own shrinkers. >> >> This patch has made the shrinker_list traversal lockless and shrinker >> register remain fast. For the shrinker unregister, atomic counter >> has been introduced to avoid synchronize_rcu() call. The fields of > > So, do you want to enhance unregister shrinker path as well as registering? > Yes, I don't want to add delay to unregister_shrinker for the normal case where there isn't any readers (i.e. unconditional synchronize_rcu). >> struct shrinker has been rearraged to make sure that the size does >> not increase for x86_64. >> >> The shrinker functions are allowed to reschedule() and thus can not >> be called with rcu read lock. One way to resolve that is to use >> srcu read lock but then ifdefs has to be used as SRCU is behind >> CONFIG_SRCU. Another way is to just release the rcu read lock before >> calling the shrinker and reacquire on the return. The atomic counter >> will make sure that the shrinker entry will not be freed under us. > > Instead of adding new lock, could we simply release shrinker_rwsem read-side > lock in list traveral periodically to give a chance to hold a write-side > lock? > Greg has already pointed out that this patch is still not right/safe and now I am getting to the opinion that without changing the shrinker API, it might not be possible to do lockless shrinker traversal and unregister shrinker without synchronize_rcu(). Regarding your suggestion, do you mean to add periodic release lock and reacquire using down_read_trylock() or down_read()? -- 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>
