On Fri, Aug 20, 2010 at 10:32 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > Le vendredi 20 août 2010 à 10:16 -0400, yao zhao a écrit : > >> if it is not performance critical, you should use the >> read_lock/write_lock, it should make the readers happier than >> spinlock. the name "mutex" is a little bit confuse. > > Yes, I mentioned the 'mutex' name oddity. > > Point is : > > We want to remove read_write locks. They dont fit the bill. > > If performance critical, lot of readers -> RCU (a lot faster) > If not, or too much writers versus readers -> spinlock (a bit faster) > > for writers more than readers of course spin will be better, that is what read/write lock for and spin for. But the case here is whether these register_ip_vs_scheduler or unregister are more frequent than the readers. if not definitely read_lock will better than spin_lock. although worse than rcu. > >> synchronize_rcu() is not necessary when you only need to delete from a >> list as it is atomic. >> > > Thats a rather strange and completely wrong claim. A big part of RCU job > is to have appropriate work done on deletes. Inserts are more easy (only > needs a smp_wmb()) > > Take a look at Documentation/RCU/* before saying such things ;) > > Not only synchronize_rcu() is not enough to protect this kind of code, > but you need something stronger. > > > The code here is deleting a global from the list, am I right? I didn't see any called case. what are you going to do more? free it? write_unlock_bh should make the mb. yao -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
