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.
