Messages in this thread | | | Date | Fri, 22 Aug 2008 13:53:39 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu |
| |
On Fri, Aug 22, 2008 at 03:03:13PM -0500, Christoph Lameter wrote: > Paul E. McKenney wrote: > > > I was indeed thinking in terms of the free from RCU being specially marked. > > Isnt there some way to shorten the rcu periods significantly? Critical > sections do not take that long after all.
In theory, yes. However, the shorter the grace period, the greater the per-update overhead of grace-period detection -- the general approach is to use a per-CPU high-resolution timer to force RCU grace period processing every 100 microseconds or so. Also, by definition, the RCU grace period can be no shorter than the longest active RCU read-side critical section. Nevertheless, I have designed my current hierarchical RCU patch with expedited grace periods in mind, though more for the purpose of reducing latency of long strings of operations that involve synchronize_rcu() than for cache locality.
> If the RCU periods are much shorter then the chance of cache hotness of the > objects is increased.
How short does the grace period need to be to significantly increase the chance of an RCU-protected data element remaining in cache across an RCU grace period? The last time I calculated this, the knee of the curve was at a few tens of milliseconds, but to give you an idea of how long ago that was, the workload I used was TPC/A. Which might no longer be very representative. ;-)
Thanx, Paul
| |