On Sat, 27 Jan 2007 02:30:17 +0530 Dipankar Sarma <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
