Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcingdelay from HZ

From: Peter Zijlstra
Date: Tue May 21 2013 - 09:25:22 EST

On Thu, May 16, 2013 at 06:22:10AM -0700, Paul E. McKenney wrote:
> > But somehow I imagined making a CPU part of the GP would be easier than taking
> > it out. After all, taking it out is dangerous and careful work, one is not to
> > accidentally execute a callback or otherwise end a GP before time.
> >
> > When entering the GP cycle there is no such concern, the CPU state is clean
> > after all.
> But that would increase the overhead of GP initialization. Right now,
> GP initialization touches only the leaf rcu_node structures, of which
> there are by default one per 16 CPUs (and can be configured up to one per
> 64 CPUs, which it is on really big systems). So on busy mixed-workload
> systems, this approach increases GP initialization overhead for no
> good reason -- and on systems running these sorts of workloads, there
> usually aren't "sacrificial lamb" timekeeping CPUs whose utilization
> doesn't matter.

Right, so I read through some of the fqs code to get a better feel for
things and I suppose I see what you're talking about :-)

The only thing I could come up with is making fqslock a global/local
style lock, so that individual CPUs can adjust their own state without
bouncing the lock around.

It would make the fqs itself a 'bit' more expensive but ideally those
don't happen that often, ha!.

But yeah, every time you let the fqs propagate 'idle' state up the tree
your join becomes more expensive too.
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