Messages in this thread | | | Date | Tue, 21 May 2013 11:45:31 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ |
| |
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.
| |