* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

quoted text
> RCU can only control the lifetime of allocated memory blocks, which 
> forces all the call structures to be allocated.  This is expensive 
> compared to allocating them on the stack, which is the common case for 
> synchronous calls.
> 
> This patch takes a different approach.  Rather than using RCU, the 
> queues are managed under rwlocks.  Adding or removing from the queue 
> requires holding the lock for writing, but multiple CPUs can walk the 
> queues to process function calls under read locks.  In the common 
> case, where the structures are stack allocated, the calling CPU need 
> only wait for its call to be done, take the lock for writing and 
> remove the call structure.
> 
> Lock contention - particularly write vs read - is reduced by using 
> multiple queues.

hm, is there any authorative data on what is cheaper on a big box, a 
full-blown MESI cache miss that occurs for every reader in this new 
fastpath, or a local SLAB/SLUB allocation+free that occurs with the 
current RCU approach?

	Ingo
--
unsubscribe notice
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/