On Wed, 10 Jun 2009, Patrick McHardy wrote: > Patrick McHardy wrote: > > Patrick McHardy wrote: > > > Pablo Neira Ayuso wrote: > > > > Can you see any problem with this optimistic approach? I know, it can > > > > potentially try to restore the cache, but this is very unlikely to > > > > happen? > > > > > > Its probably quite unlikely, so not a big issue. OTOH this is > > > effectively doing something quite similar to a spinlock. Maybe > > > its finally time to add per-conntrack locking. > > > > > > Eric even had a patch for this IIRC :) > > > > I'll take a quick stab at this, will let you know in 30-60 minutes. > > This is a first attempt to replace some global locks by private > per conntrack locks. On 64 bit, it fits into a hole and doesn't > enlarge struct nf_conn. [...] > Now is that really better - I'm not sure myself :) The per-conntrack > locking would be an improvement though. What do you think? I think it's cool and highly required, in order to add per hash bucket locks too :-). And hash bucket locking can even more improve performance. (We need the ordered locking of the buckets for both directions only when entries are added/deleted, otherwise a single read-lock of the given bucket is enough.) Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
