On 05.08.2018 15:50, Matthew Wilcox wrote: > On Sun, Aug 05, 2018 at 08:30:43AM +0300, Kirill Tkhai wrote: >> On 05.08.2018 03:03, Matthew Wilcox wrote: >>> On Sat, Aug 04, 2018 at 09:42:05PM +0300, Kirill Tkhai wrote: >>>> This is exactly the thing the patch makes. Instead of inserting a shrinker >>>> pointer >>>> to idr, it inserts a fake value SHRINKER_REGISTERING there. The patch >>>> makes impossible >>>> to dereference a shrinker unless it's completely registered. >>> >>> - id = idr_alloc(&shrinker_idr, shrinker, 0, 0, GFP_KERNEL); >>> + id = idr_alloc(&shrinker_idr, SHRINKER_REGISTERING, 0, 0, >>> GFP_KERNEL); >>> >>> Instead: >>> >>> + id = idr_alloc(&shrinker_idr, NULL, 0, 0, GFP_KERNEL); >>> >>> ... and the rest of your patch becomes even simpler. >> >> The patch, we are discussing at the moment, does *exactly* this: >> >> https://lkml.org/lkml/2018/8/3/588 >> >> It looks like you missed this hunk in the patch. > > No, it does this: > > + id = idr_alloc(&shrinker_idr, SHRINKER_REGISTERING, 0, 0, GFP_KERNEL); > > I'm saying do this: > > + id = idr_alloc(&shrinker_idr, NULL, 0, 0, GFP_KERNEL);
No, this won't work at all. The patch introduces special value SHRINKER_REGISTERING, because shrink_slab_memcg() needs to differ the cases, when 1)shrinker is registering and 2)shrinker is unregistered. In case of shrinker is registering we do not clear the bit in shrink_slab_memcg(), while in the other case we must do that. This introduce a generic solution for all type of shrinkers, and this allows to not impose restrictions on specific shrinker registering code. A user of shrinker may add a first element to its LRU list before register_shrinker_prepared() is called, and the corresponding bit won't be cleared. This gives flexibility for users, it's just the same flexibility they have now. Before the patch, list_empty() was used like such the indicator, and this is the difference the patch makes.
