Hi Tejun, On 07/26, Tejun Heo wrote: > > > __rcu_sync_enter(rsp, false) works just like rcu_sync_enter_start() but it can > > be safely called at any moment. > > Yeah, I originally used rcu_sync_enter_start() but quickly found out that it > can't be reverted reliably. Given how cold the option switching path is, I > think it's fine to pay an extra synchronize_rcu() there rather than adding > more complexity to rcu_sync_enter() unless this will be useful somewhere > else too. Yes, agreed. As I said, this is just for record, so that I can find this (simple) patch on lkml if we have another user of __rcu_sync_enter(rsp, bool wait). > > And can't resist, off-topic question... Say, cgroup_attach_task_all() does > > > > mutex_lock(&cgroup_mutex); > > percpu_down_write(&cgroup_threadgroup_rwsem); > > > > and this means that synchronize_rcu() can be called with cgroup_mutex held. > > Perhaps it makes sense to change this code to do > > > > rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); > > mutex_lock(&cgroup_mutex); > > percpu_down_write(&cgroup_threadgroup_rwsem); > > ... > > percpu_up_write(&cgroup_threadgroup_rwsem); > > mutex_unlock(&cgroup_mutex); > > rcu_sync_exit(&cgroup_threadgroup_rwsem.rss); > > > > ? Just curious. > > I'm not quite following. Me too ;) > Are you saying that if we switching the rwsem into > slow mode before grabbing the locks, we can avoid inducing latencies on > other users? Well yes, in that another mutex_lock(&cgroup_mutex) won't sleep until synchronize_rcu() (called under cgroup_mutex) completes. > Hmm... assuming that I'm understanding you correctly, one > problem with that approach is that everyone would be doing synchronize_rcu() > whether they want to change favoring state. Hmm... I didn't mean the changing if favoring state... And in any case, this won't cause any additional synchronize_rcu(). Nevermind, please forget, this probably makes no sense. Oleg.
