Re: [patch] latency tracer, 2.6.15-rc7

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Fri, Dec 30, 2005 at 11:54:14PM -0500, Lee Revell wrote:
> On Fri, 2005-12-30 at 20:29 -0800, Paul E. McKenney wrote:
> > This should help in UP configurations, or in SMP configurations where
> > all CPUs are doing call_rcu_bh() very frequently.  I would not expect
> > it to help in cases where one of several CPUs is frequently executing
> > call_rcu_bh(), but where the other CPUs are either CPU-bound in user
> > space or are in a tickful idle state. 
> 
> This and net/decnet/dn_route.c are the only two uses of call_rcu_bh in
> the kernel.  And this one does not seem to be invoked frequently, it
> took ~48 hours to show up in the latency tracer.  Of course a server
> workload might call it all the time.

Well, most old-style server workloads wouldn't notice a 10ms hit to
latency.  I expect server workloads to become much more sensitive to
latency over time, however.  There are several reasons for this:
(1) as more and more workloads are spread over many machines, the
latency of each individual machine must improve just to maintain
the same overall latency (2) as computers continue to get less expensive
relative to people (and this trend is most pronounced in -developing-
countries, -not- developed countries!), it will be less and less
acceptable to have people waiting on computers (3) the trend of which
VOIP is part will continue, so that traditional server workloads will
have increasingly large latency-sensitive components.

But back to the problem at hand.

So it seems to me that Linus's patch is part of the solution, but
needs to also have a global component, perhaps as follows:

	if (unlikely(rdp->count > 100)) {
		set_need_resched();
		if (unlikely(rdp->count - rdp->last_rs_count > 1000)) {
			int cpu;

			rdp->last_rs_count = rdp->count;
			spin_lock_bh(&rcu_bh_state.lock);
			for_each_cpu_mask(cpu, rdp->rcu_bh_state.cpumask)
				smp_send_reschedule(cpu);
			spin_unlock_bh(&rcu_bh_state.lock);
		}
	}

I am sure that I am missing some interaction or another with tickless
idle and CPU hotplug covered.

There also needs to be some adjustment in rcu_do_batch(), which will
have to somehow get back to a quiescent state periodically.  Dipankar,
Vatsa, thoughts?

							Thanx, Paul