Messages in this thread |  | | | Date | Tue, 10 Jan 2006 21:44:56 +0100 | | From | Manfred Spraul <> | | Subject | Re: [PATCH 4/5] rcu: join rcu_ctrlblk and rcu_state |
| |
[I haven't read the diff, just a short comment]
Dipankar Sarma wrote:
>rcu_state came over from Manfred's RCU_HUGE patch IIRC. I don't >think it is necessary to allocate rcu_state separately in the >current mainline RCU code. So, the patch looks OK to me, but >Manfred might see something that I am not seeing. > > > The two-level rcu code was never merged, I still plan to clean it up.
But the idea of splitting the control block and the state is used in the current code: - __rcu_pending() is the hot path, it only performs a read access to rcu_ctrlblk. - write accesses to the rcu_ctrlblk are really rare, they only happen when a new batch is started. Especially: independant from the number of cpus.
Write access to the rcu_state are common: - each cpu must write once in each cycle to update it's cpu mask. - The last cpu then completes the quiescent cycle.
The idea is that rcu_state is more or less write-only and rcu_state is read-only. Theoretically, rcu_state could be shared in all cpus caches, and there will be only one invalidate when a new batch is started. Thus no cacheline trashing due to rcu_pending calls. I think it would be safer to keep the two state counters in a separate cacheline from the spinlock and the cpu mask, but I don't have any hard numbers. IIRC the problems with the large SGI systems disappered, and everyone was happy. No real benchmark comparisons were made.
-- Manfred - 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/
|  |