Ah. Is it OK for us to keep complaining about you removing it though?
On Tue, Aug 20, 2013 at 01:10:06PM -0700, Ethan Jackson wrote: > 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
