On 09.08.2018 13:37, Tetsuo Handa wrote: > On 2018/08/09 18:21, Kirill Tkhai wrote: >> 2)SRCU. Pros are there are no the above problems; we will have completely >> unlocked and >> scalable shrink_slab(). We will also have a possibility to avoid >> unregistering delays, >> like I did for superblock shrinker. There will be full scalability. >> Cons is enabling SRCU. >> > > How unregistering delays can be avoided? Since you traverse all shrinkers > using one shrinker_srcu, synchronize_srcu(&shrinker_srcu) will block > unregistering threads until longest inflight srcu_read_lock() user calls > srcu_read_unlock().
Yes, but we can do synchronize_srcu() from async work like I did for the further patches. The only thing we need is to teach shrinker::count_objects() and shrinker::scan_objects() be safe to be called on unregistering shrinker user. The next patches do this for superblock shrinker. > Unless you use per shrinker counter like below, I wonder whether > unregistering delays can be avoided... > > https://marc.info/?l=linux-mm&m=151060909613004 > https://marc.info/?l=linux-mm&m=151060909713005 I'm afraid these atomic_{inc,dec}(&shrinker->nr_active) may regulary drop CPU caches on another CPUs on some workloads. Also, synchronize_rcu() is also a heavy delay.
