On 4 March 2014 14:49, Ben Pfaff <b...@nicira.com> 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.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
