> On 16 Aug 2016, at 08:28, Mark Kettenis <[email protected]> wrote: > >> 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.
art_walk modifies the table refcnts, which are serialised by the lock. taking a write lock is still necessary. > Thanks for the explanation.
