On Thu, Oct 27, 2022 at 6:00 AM Adrian Moreno <[email protected]> wrote: > > > > On 10/26/22 18:41, Adrian Moreno wrote: > > > > > > On 10/21/22 18:57, Mike Pattrick wrote: > >> On Fri, Sep 30, 2022 at 11:31 AM Adrian Moreno <[email protected]> wrote: > >>> > >>> Currently, things like the number of handler and revalidator threads are > >>> calculated based on the number of available CPUs. However, this number > >>> is considered static and only calculated once, hence ignoring events > >>> such as cpus being hotplugged, switched on/off or affinity mask > >>> changing. > >>> > >>> This patch makes the number of cpus be calculated every time it's > >>> needed. > >>> > >>> As a result of these changes (assuming the patch is backported): > >>> - >=2.16: a change in the cpu affinity immediately reflects on > >>> the number of threads. > >>> - < 2.16: a change in the cpu affinity will be reflected on > >>> the number of threads the next time there is a call to > >>> bridge_reconfigure() (e.g: on the next DB change). > >>> > >>> The difference in behavior is because on older versions the thread > >>> number calculation was done on bridge reconfiguration while newer > >>> versions moved this logic down to the dpif layer and is run on > >>> dpif->run() stage. > >>> Considering it has not been a huge problem up to today and that the > >>> cpu change would be reflected sooner or later (e.g the user could > >>> force a recalculation with a simple ovs-vsctl command), I think it > >>> might be OK to leave like that. > >>> > >> > >> Count_cpu_cores() is called many times per second in the main thread, > >> not just in bridge_reconfigure, but also in type_run. Would this > >> impact the performance of bridge_run? Or are these concerns > >> unjustified? > >> > > > > Performance concerns are never unjustified :) > > > > I think a couple of syscalls will not add a significant delay on the main > > loop > > that would justify a more complex solution (e.g: a timer?). What do you > > think? > > > > I can benchmark it to get a ballpark idea of it's effects. > > > > I've seen a delay of up to 4.6% in the main loop duration. Also, I've > measured a > much more problematic (yet unlikely) potential problem: the throughput impact > of > deleting the threads and re-creating them several times per second (it would > mean affinity changes that often). The impact is very high. > > I tried a timer-based approach with a sampling period of 5 seconds. In my > tests, > it yields a main thread duration increase of <1% (which is probably within the > measurement error interval) and reasonably contained performance impact of <5% > in the worst-case scenario of the kernel cache being disabled (all traffic is > processed by a handler). > > What do you think?
I think the results from your 5 second holdover test are very promising, that definitely seems like the way forward. Cheers, M > > Thanks. > -- > Adrián Moreno > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
