Re: [PATCH 00/10] rcu: Cleanup RCU tree initialization

From: Paul E. McKenney
Date: Mon Mar 09 2015 - 17:35:59 EST

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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at