> Date: Tue, 16 Aug 2016 08:21:42 +1000 > From: Jonathan Matthew <[email protected]> > > On Mon, Aug 15, 2016 at 02:47:29PM +0200, Mark Kettenis wrote: > > > Date: Mon, 15 Aug 2016 22:08:16 +1000 > > > From: Jonathan Matthew <[email protected]> > > > > > > This removes ART's reliance on the kernel lock to serialise > > > updates. I sent out an earlier version of this prior to 6.0, > > > but it didn't make it in. Since then, we've decided to go with > > > rwlocks in the packet processing path, so here's a version with > > > an rwlock instead of a mutex. > > > > Merely out of curiousity: is there any reason to only use write locks > > here? Naively you'd think this would be a case where making use of > > the multiple-reader, single-writer property of rwlocks would make > > sense... > > The read operations that need to be fast don't go through the lock > at all. We could use read locks for rtable_walk, but we're unlikely > to see concurrent rtable_walks, and I'd prefer to keep the lock use > as simple as possible for now.
Thanks for the explanation.
