lkml.org 
[lkml]   [2015]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2015-03-09 22:41    [W:0.801 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site