On Wed, Mar 05, 2014 at 10:47:33AM -0800, Joe Stringer wrote: > On 4 March 2014 14:49, Ben Pfaff <[email protected]> wrote: > > > After studying the code for a while, I think I see something odd. > > Each 'ukeys' hmap is associated with a revalidator thread, but the > > hmaps have barely any relationship with their owning thread. Except > > during the "sweep", it's not more likely, for example, that a thread > > will access a ukey in its hmap than in any other hmap. > > > > I agree with this assessment. The dump phase has even distribution of > access, then there is a barrier before each thread handles garbage > collection for its own hmap. > > > > If we were to maintain the ukeys hmaps separately, then we wouldn't > > have to have the same number of hmaps as threads. That seems, > > off-hand, like a good thing, since the degree of parallelism depends > > on the number of hmaps as well as on the number of threads: increasing > > the number of hmaps, while holding the number of threads constant, > > will still help somewhat. > > > > What do you think? > > > > I think it's worth exploring, but I'd like to explore it independently of > this patch. It's not entirely obvious to me right now that contention on > these hmaps is a problem. That is to say, currently we spend far more time > in action translation for pushing stats than we do contending on > revalidator hmaps. Another patchset I plan to post RFC this week will begin > to address this area, and I have some ideas about sharing these hmaps with > handler threads; that looks like a more logical time to visit this.
OK. It took me some studying to figure out what was going on, so let me suggest a simple way to make it clearer: move the ukeys hmaps, and the associated mutexes, out of the revalidator-specific structs into the parent udpif. Then at least it doesn't look at first glance like the hmaps are basically owned by the threads. What do you think of that idea? _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
