On Mon, Mar 26, 2018 at 06:20:55PM +0300, Kirill Tkhai wrote: > On 24.03.2018 21:45, Vladimir Davydov wrote: > > On Wed, Mar 21, 2018 at 04:21:29PM +0300, Kirill Tkhai wrote: > >> The patch introduces mcg_shrinkers array to keep memcg-aware > >> shrinkers in order of their shrinker::id. > >> > >> This allows to access the shrinkers dirrectly by the id, > >> without iteration over shrinker_list list. > > > > Why don't you simply use idr instead of ida? With idr you wouldn't need > > the array mapping shrinker id to shrinker ptr. AFAIU you need this > > mapping to look up the shrinker by id in shrink_slab. The latter doesn't > > seem to be a hot path so using idr there should be acceptable. Since we > > already have shrinker_rwsem, which is taken for reading by shrink_slab, > > we wouldn't even need any additional locking for it. > > The reason is ida may allocate memory, and since list_lru_add() can't fail, > we can't do that there. If we allocate all the ida memory at the time of > memcg creation (i.e., preallocate it), this is not different to the way > the bitmap makes. > > While bitmap has the agvantage, since it's simplest data structure (while > ida has some radix tree overhead). > > Also, bitmap does not require a lock, there is single atomic operation > to set or clear a bit, and it scales better, when anything. I didn't mean the per-memcg bitmaps - I think it's OK to use plain arrays for them and reallocate them with the aid of RCU. What I actually mean is the mapping shrink_id => shrinker. AFAIU it isn't accessed from list_lru, it is only needed to look up a shrinker by id from shrink_slab(). The latter is rather a slow path so I think we can use an IDR for this mapping instead of IDA + plain array.
