Re: Q: locking mechanisms

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Tue, Jul 04, 2006 at 02:58:42PM +0200, Urs Thuermann wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> 
> > Does Documentation/listRCU.txt answer your questions ?
> 
> It doesn't answer my question.  I have code that receives network
> packets by registering with dev_add_pack().  Each packet received is
> then delivered to a list of receivers, where this list can contain quite
> a lot of items:
> 
> 	receive_function(struct sk_buff *skb, struct net_device *dev,
> 			struct packet_type *pt, struct net_device *orig_dev)
> 	{
> 		...
> 		rcu_read_lock();
>                 head = find_list(dev);
> 		hlist_for_each_entry_rcu(p, n, head, list) {
> 			deliver_packet_to_receiver(skb, p);
> 		}
> 		rcu_read_unlock();
> 	}
> 
> The deliver_packet_to_receiver() function finally ends up in a call to
> sock_queue_rcv_skb().
> 
> My questions was, wether I should worry to "hold" the rcu_read_lock for
> the time of the list traversal since the list can be quite long and
> preemption is disabled between rcu_read_lock() and rcu_read_unlock().

"Holding" rcu_read_lock() for long time periods is much less of a
concern than holding other types of synchronization mechanisms.
The main concern is the effect on realtime latency in CONFIG_PREEMPT
(but -not- CONFIG_PREEMPT_RT) kernels.  This concern is due to the
fact that rcu_read_lock() suppresses preemption in CONFIG_PREEMPT
kernels.

But I have to ask: roughly how long is "quite long"?

							Thanx, Paul
-
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/