Messages in this thread | | | Date | Mon, 9 Mar 2015 14:35:42 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 00/10] rcu: Cleanup RCU tree initialization |
| |
On Mon, Mar 09, 2015 at 09:36:52AM +0000, Alexander Gordeev wrote: > On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote: > > Hi Paul, > > > > Here is cleanup of RCU tree initialization rebased on linux-rcu rcu/next > > repo, as you requested. Please, note an extra patch #10 that was not > > present in the first post. > > Paul, > > Please, ignore patch #10 for now. I missed to notice rcu_node::grpnum is > used in tracing, so the patch is incomplete. I am not sure why trailing > spaces in seq_printf(m, "%lx/%lx->%lx %c%c>%c %d:%d ^%d ", ....) are > needed for, so not sure if "^%d" part should be removed (possibly with > the traling spaces) or replaced with three spaces.
OK, dropping this one for the moment.
The original use of ->grpnum was for manual debugging purposes. Yes, you can get the same information out of ->grpmask, but the number is easier to read. And on the debugfs trace information, ->grpnum is printed, but ->grpmask is not.
The trailing spaces on the seq_printf() allow the rcu_node data to be printed on a single line, while still allowing the eye to pick out where one rcu_node structure's data ends and the next one begins.
So here are the choices, as far as I can see:
1. Leave ->grpnum as is.
2. Remove ->grpnum, but regenerate it in print_one_rcu_state(), for example, by counting the number of rcu_node structures since the last ->level change.
3. Drop ->grpnum and also remove it from the debugfs tracing. The reader can rely on the ->grplo and ->grphi fields to work out where this rcu_node structure fits in, but we lose the visual indication of any bugs in computing these quantities.
4. Drop ->grpnum and replace it with ->grpmask. This seems a bit obtuse to me.
5. Redesign print_one_rcu_state()'s output from scratch.
#1 has certain advantages from a laziness viewpoint. #2 would open up some space in the rcu_node structure, but space really isn't an issue for that structure given that huge systems have only 257 of them and the really small systems use Tiny RCU instead. #3 might be OK, but I am not really convinced. #4 seems a bit ugly. I am not signing up for #5, in part because not all that many people use RCU's debugfs output, so I don't see the point in investing the time.
But what did you have in mind?
Thanx, Paul
| |