On Wed, Apr 07, 2004 at 05:23:28PM +0200, Robert Olsson wrote:
> Dipankar Sarma writes:
>
> > Robert, you should try out rs-throttle-rcu.patch. The idea is that
> > we don't run too many callbacks in a single rcu. In my setup,
> > at 100kpps, I see as many as 30000 rcu callbacks in a single
> > tasklet handler. That is likely hurting even the softirq-only
> > RCU grace periods. Setting rcupdate.maxbatch=4 will do only 4 per
> > tasklet thus providing more quiescent points to the system.
>
> Hello!
>
> No bad things happens, lots of overflows and drop in performance
> and the userland app can stall for 32 sec. We seems to spin in
> softirq to much and still don't get things done.
Argh!! Andrea, this means that throttling rcu callbacks with
back-to-back rcu tasklets for better scheduling latency is bad
for this kind of DoS situation. I think we will have to address
the softirq limiting question.
That said, Robert, one last experiment - if you are running UP,
can you try the following patchset (should apply on top of vanilla
2.6.x) ? This implements direct invocation of callbacks instead
of waiting for rcu grace periods in UP kernel. This would be a
good data point to understand what happens.
Thanks
Dipankar
rcu-rt-latency.patch
Description: Text document
dcache-rcu-latency.patch
Description: Text document
rtcache-rcu-latency.patch
Description: Text document
|