On 07/08/20 12:05, Valentin Schneider wrote: > > AFAIU rcu_read_lock() is light weight. So having the protection applied is more > > robust against future changes. > > So I think the one thing you win by having this dance with mb's and the > suggested handling of the task list is that you do not need any > rcu_synchronize() anymore. Both approaches have merit, it's just that the > way I understood the suggestion to add sched_post_fork() was to simplify > the ordering of the update with the aforementioned scheme. The synchronize_rcu() is not for sched_post_fork(). It is to deal with the preemption problem. > > > > >> > >> sched_post_fork() being preempted out is a bit more annoying, but what > >> prevents us from making that bit preempt-disabled? > > > > preempt_disable() is not friendly to RT and heavy handed approach IMO. > > > > True, but this is both an infrequent and slow sysctl path, so I don't think > RT would care much. There's an easy answer for that. But first I'm not sure what problem are we discussing here. What is the problem with rcu? And how is preempt_disable() fixes it or improves on it? Thanks -- Qais Yousef
