This is again a summary of what was presented at the OLS 2002
RCU paper.
One other aspect of different RCU implementations that we have
been investigating is the update latency. That is, how long
it takes to complete the grace period and do the actual update.
Long latencies could result in system running out of memory.
I measured this for 3 different RCU implementations - rcu_poll,
rcu_ltimer and rcu_sched against varying number of clients in
dbench with the lockfree dcache lookup patch using RCU for dentries.
The results can be seen in the following graph -
http://lse.sourceforge.net/locking/ols2002/rcu/results/latency/latency.png
It is logscale on y axis, in case you don't notice it.
The patches are same as the ones used in overhead measurements -
http://lse.sourceforge.net/locking/ols2002/rcu/patches/
1. rcu_poll, with its forced reschedule and aggressive
polling, shows the best latency.
2. The latencies for all these RCU implementations remain
reasonably flat under increased load.
Comments/suggestions ?
Thanks
-- Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:17 EST
