Re: [PATCH] RCU for low latency (experimental)

Dipankar Sarma
2004-03-28T17:21:50Z

On Sun, Mar 28, 2004 at 06:53:47PM +0200, Takashi Iwai wrote:
> At Thu, 25 Mar 2004 05:16:43 +0530,
> Dipankar Sarma wrote:
> >
> > On Thu, Mar 25, 2004 at 12:34:30AM +0100, Andrea Arcangeli wrote:
> > > On Thu, Mar 25, 2004 at 04:41:45AM +0530, Dipankar Sarma wrote:
> > > > That was not 16 callbacks per tick, it was 16 callbacks in one
> > > > batch of a single softirq. And then I reschedule the RCU tasklet
> > >
> > > sorry so you're already using tasklets in current code? I misunderstood
> > > the current code then.
> >
> > + if (count >= rcumaxbatch) {
> > + RCU_plugticks(cpu) = rcuplugticks;
> > + if (!RCU_plugticks(cpu))
> > + tasklet_hi_schedule(&RCU_tasklet(cpu));
> > + break;
> > + }
>
> it seems count is never incremented in your patch...
> or am i missing something?

I messed it up when I forward ported the throttle-rcu.patch
from 2.6.0+lots-of-instrumentation to 2.6.4-vanilla in order
to publish in lkml. The original patch did this -

@@ -110,6 +113,10 @@ static void rcu_do_batch(int cpu, struct
head->func(head->arg);
RCU_nr_rcupdates(cpu)++;
count++;
+ if (count >= rcumaxbatch) {
+ RCU_plugticks(cpu) = rcuplugticks;
+ break;
+ }
}

Sorry about that.

> anyway, i confirmed that with the original krcud patch the latency
> with dcache flood can be eliminated.

Does the throttle-rcu patch also help eliminate dcache flood ? You
can try by just changing count >= rcumaxbatch to ++count > rcumaxbatch.

>
> for the non-preemptive case, rcu_bh_callback_limit() should return
> bhlimit always, though. otherwise cond_resched() isn't called in the
> callback loop properly.

Yes, I think we should consider using limiting even in the non-preemptive
case.

Thanks
Dipankar