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

[Dipankar Sarma <dipankar@in.ibm.com>]

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