Messages in this thread | | | Date | Sun, 20 Oct 2013 09:58:07 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 4/6] rcusync: Introduce struct rcu_sync_ops |
| |
On Fri, Oct 18, 2013 at 02:10:15PM +0200, Oleg Nesterov wrote: > On 10/18, Lai Jiangshan wrote: > > > > On 10/17/2013 11:42 PM, Paul E. McKenney wrote: > > > On Thu, Oct 17, 2013 at 10:07:15AM +0800, Lai Jiangshan wrote: > > >> On 10/08/2013 06:25 PM, Peter Zijlstra wrote: > > >>> From: Oleg Nesterov <oleg@redhat.com> > > >>> > > >>> Add the new struct rcu_sync_ops which holds sync/call methods, and > > >>> turn the function pointers in rcu_sync_struct into an array of struct > > >>> rcu_sync_ops. > > >> > > >> Hi, Paul > > >> > > >> I think this work should be done in rcupdate.[ch] side by introducing > > >> struct rcu_flavor. > > > > > > I -do- have on my list to add an rcutorture test for rcu_sync, but > > > what do you have in mind by adding struct rcu_flavor? I am guessing > > > that you do not mean to try to create an rcu_state and a set of > > > > No. > > The thing what I need is just as same as Oleg Nesterov implemented. > > It is just a structure with several function pointers for different RCU variants. > > But it would be better if we implement in rcupdate.[ch], > > and name it to struct rcu_flavor like the URCU. > > > > After we have struct rcu_flavor, we can replace the following code > > to a pointer to struct rcu_flavor. > > > > struct rcu_state: > > void (*call)(struct rcu_head *head, /* call_rcu() flavor. */ > > void (*func)(struct rcu_head *head)); > > > > struct rcu_torture_ops { > > int (*readlock)(void); > > void (*readunlock)(int idx); > > void (*sync)(void); > > void (*exp_sync)(void); > > void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu)); > > void (*cb_barrier)(void); > > }; > > Yes, probably. But it is not clear how/when this rcu_sync will be merged. > (I hope it will be merged anyway, if nothing else I'll resend these patches > for percpu_rw_semaphore with other updates in percpu-rwsem.c). > > Until then, perhaps you can add rcu_flavor/whatever in rcupdate.* ? Then > rcu_sync can be triviallly updated to use the ops we have in rcupdate. > And rcutorture.c of course. > > IOW, I think that this should be a separate change, before or after > rcu_sync.
Perhaps put it in the shiny new kernel/rcu directory in -tip?
Thanx, Paul
| |