Messages in this thread | | | Date | Fri, 26 Jan 2007 13:25:45 -0800 | From | Andrew Morton <> | Subject | Re: [mm PATCH 4/6] RCU: preemptible RCU |
| |
On Sat, 27 Jan 2007 02:30:17 +0530 Dipankar Sarma <dipankar@in.ibm.com> wrote:
> > > As a consequence of keeping track of RCU readers, the readers > > > have a slight overhead (optimizations in the paper). > > > This implementation co-exists with the "classic" RCU > > > implementations and can be switched to at compiler. > > > > That's yet another question we need to ask people when their kernel dies, > > and yet another deviation between the kernels which we all test, causing > > more dilution of testing efforts. It would be much better if we could > > remove classic RCU. You say this would incur extra cost, but the magnitude > > of that cost is not clear. Please help us make that decision. > > See the Table 2, page 10 of the paper mentioned above.
argh.
Seems I have to wade through half the paper to understand Table 2.
> There is a > ~100ns cost per read-side critical section involved in the preemptible > version of RCU at the moment. Until, we are sure that we don't have > an impact on common workloads, we need to keep the "classic" > implementation around.
Ratios, please.. that 100ns appears to be a 100% increase. ie 100ns -> 200ns.
There are a couple of ways of working out how much that really matters: a) run a workload or b) instrument a kernel, work out how many times/sec the kernel runs rcu_read_lock(). I suspect b) would be more useful and informative.
Either way, please always prepare such info up-front and summarise in the changelog? It's kinda important... - 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/
| |