[lkml]   [2008]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH, RFC] v7 scalable classic RCU implementation
Paul E. McKenney wrote:
>> Attached is a hack that I use right now for myself.
>> Btw - on my 4-cpu system, the average latency from call_rcu() to the rcu
>> callback is 4-5 milliseconds, (CONFIG_HZ_1000).
> Hmmm... I would expect that if you have some CPUs in dyntick idle mode.
> But if I run treercu on an CONFIG_HZ_250 8-CPU Power box, I see 2.5
> jiffies per grace period if CPUs are kept out of dyntick idle mode, and
> 4 jiffies per grace period if CPUs are allowed to enter dyntick idle mode.
> Alternatively, if you were testing with multiple concurrent
> synchronize_rcu() invocations, you can also see longer grace-period
> latencies due to the fact that a new synchronize_rcu() must wait for an
> earlier grace period to complete before starting a new one.
That's the reason why I decided to measure the real latency, from
call_rcu() to the final callback. It includes the delays for waiting
until the current grace period completes, until the softirq is
scheduled, etc.
Probably one cpu was not in user space when the timer interrupt arrived.
I'll continue to investigate that. Unfortunately, my first attempt
failed: adding too many printk's results in too much time spent within
do_syslog(). And then the timer interrupt always arrives on the
spin_unlock_irqrestore in do_syslog()....


 \ /
  Last update: 2008-11-05 20:53    [W:0.104 / U:1.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site