I never removed it, just complained about it. Ethan
On Tue, Aug 20, 2013 at 12:47 PM, Ben Pfaff <b...@nicira.com> wrote: > On Sun, Aug 18, 2013 at 02:56:55PM +1000, Simon Horman wrote: >> On Thu, Aug 08, 2013 at 02:37:48PM -0700, Ben Pfaff wrote: >> > On Thu, Aug 08, 2013 at 02:32:08PM -0700, Ethan Jackson wrote: >> > > > Simon presented numbers that showed it to be a valuable optimization >> > > > in some cases, otherwise I'd just say get rid of it. >> > > >> > > If that's the only reason we have it, I vote we ditch it. It's a new >> > > world with multithreading, I'd like to have a clean slate in the >> > > direction of thread safety and add optimizations back if they help in >> > > this new paradigm >> > >> > That's the only reason we have it. If you want to ditch it be my >> > guest. >> >> I accept that multi-threaded ovs-vswtichd is a whole new world >> and that dropping optimisations that previously made sense is logical. >> And I guess that the best thing is for the situation that lead to >> this optimisation to be re-profiled once the multi-threading work is more >> complete. >> >> For reference, my recollection is that this optimisation came >> about because it was observed that inserting 100k non-expirable flows >> would result in ovs-vswtichd consuming about 100% (of one) CPU running >> through the list of flows to see if any of them were ready to be expired >> although none of them ever would be. With the optimisation in place >> CPU utilisation was reduced to roughly 0% as the list that was traversed >> became empty and the system was otherwise idle. > > I think it's perfectly reasonable to reintroduce the optimization. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
